Re: [RFC] Confusing fall through BB pc in conditional jump
Hi Kewen,
On Fri, Jun 28, 2019 at 09:56:58AM +0800, Kewen.Lin wrote:
> > It's probably a good idea to spend a line on this even in slim mode, it's
> > really easy to miss and get confused and waste time without it. Nice :-)
> >
> >> The dumping will look like:
> >> 6: NOTE_INSN_BASIC_BLOCK 2
> >>...
> >>12: r135:CC=cmp(r122:DI,0)
> >>13: pc={(r135:CC!=0)?L52:pc}
> >> REG_DEAD r135:CC
> >> REG_BR_PROB 1041558836
> >> ;; pc (fall through) -> L67
> >>31: L31:
> >>17: NOTE_INSN_BASIC_BLOCK 3
> >
> > I think it should say the BB number it falls through to. Is the label
> > number (insn number) useful? Maybe the BB number isn't always printed
> > in slim dumps?
>
> OK, to use the label was meant to keep the same as what we print for jump
> targets of jump insn. Yes, I think it's better to use BB number.
> I think we can get the BB number from NOTE_INSN_BASIC_BLOCK now, it's
> always printed in slim dumps.
Ah cool. I don't often look at "normal" slim dumps, sorry if some things
I said were more confusing than helpful :-) (I see the thing combine
prints at the start of the dump a lot, but that skips all non-insns. I
should change that to make BB boundaries visible, it's pretty crucial for
combine :-) )
> > Maybe slim dumps should always spend a line on showing basic block
> > boundaries? Something visual like maybe
> > ; --
> > or
> > ; BB 456 --
> > or
> > ; falls through to BB 123
> > or
> > ; falls through to BB 123
> > ; BB 456 --
> >
>
> It seems the current NOTE_INSN_BASIC_BLOCK is enough for the beginning?
Yes, you are right. That note itself is probably enough to make it obvious
there is a BB boundary, when skimming a dump.
> > I don't use slim dumps much, they lose too much information, but maybe
> > that can be fixed :-)
>
> OK, since I haven't got used to lisp format, the slim seems more
> understandable to me. If it's not used too much, maybe this confusion
> and possible improvement is too trivial. :)
Slim dumps are much more compact, so you can do some things with it that
you cannot with "full" dumps. But they miss just a little bit *too* much
information; your patch helps to fix that. I'm all for it :-)
[ Unrelated... One of my biggest problems with slim dumps... subregs...
If it says
r128:CC=cmp(r124:DI#4,0)
then in what mode is the compare actually done? Now because I know what
target this is in which configuration, the #4 is a good hint it is SImode,
but what if it was LE so it would say #0? And for some ops you really
cannot guess at all, say when picking apart a register. ]
Segher
Re: [AArch64 ELF ABI] Vector calls and lazy binding on AArch64
On 22/05/2019 15:42, Szabolcs Nagy wrote: > [AAELF64]: ELF for the Arm 64-bit Architecture (AArch64) >https://developer.arm.com/docs/ihi0056/latest > [VABI64]: Vector Function ABI Specification for AArch64 > > https://developer.arm.com/tools-and-software/server-and-hpc/arm-architecture-tools/arm-compiler-for-hpc/vector-function-abi the new ABI has been published with minor wording changes compared to the draft version. the ABI is implemented in gcc, binutils and glibc in a series of patches listed below. gcc: commit 779640c76d37b32f4d8a7b97637ed9e345d750b4 Commit: nsz CommitDate: 2019-06-03 13:50:53 + aarch64: emit .variant_pcs for aarch64_vector_pcs symbol references git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@271869 138bc75d-0d04-0410-961f-82ee72b054a4 commit d403a7711c2cf9a7a4892d76b875a1c99a690f89 Commit: nsz CommitDate: 2019-06-04 16:16:52 + aarch64: fix asm visibility for extern symbols git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@271913 138bc75d-0d04-0410-961f-82ee72b054a4 commit 042371f341a956de8c76557df700ebdc1af9ab4f Commit: nsz CommitDate: 2019-06-18 11:11:07 + aarch64: fix gcc.target/aarch64/pcs_attribute-2.c on non-gnu targets git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@272414 138bc75d-0d04-0410-961f-82ee72b054a4 binutils: commit 2301ed1c9af1316b4bad3747d2b03f7d44940f87 Commit: Szabolcs Nagy CommitDate: 2019-05-24 15:05:57 +0100 aarch64: add STO_AARCH64_VARIANT_PCS and DT_AARCH64_VARIANT_PCS commit f166ae0188dcb89c5ae925034260a708a254ab2f Commit: Szabolcs Nagy CommitDate: 2019-05-24 15:07:42 +0100 aarch64: handle .variant_pcs directive in gas commit 0b4eac57c44ec4c9e13f5201b40936c3b3e6c639 Commit: Szabolcs Nagy CommitDate: 2019-05-24 15:09:06 +0100 aarch64: override default elf .set handling in gas commit 823710d5856996d1f54f04ecb2f7647aeae99b5b Commit: Szabolcs Nagy CommitDate: 2019-05-24 15:11:00 +0100 aarch64: handle STO_AARCH64_VARIANT_PCS in bfd commit 65f381e729bedb933f3e1376e7f53f0ff63ac9a8 Commit: Szabolcs Nagy CommitDate: 2019-05-28 12:03:51 +0100 aarch64: fix variant_pcs ld tests glibc: commit 55f82d328d2dd1c7c13c1992f4b9bf9c95b57551 Commit: Szabolcs Nagy CommitDate: 2019-06-13 09:44:44 +0100 aarch64: add STO_AARCH64_VARIANT_PCS and DT_AARCH64_VARIANT_PCS commit 82bc69c012838a381c4167c156a06f4598f34227 Commit: Szabolcs Nagy CommitDate: 2019-06-13 09:45:00 +0100 aarch64: handle STO_AARCH64_VARIANT_PCS
Threadsafe Garbage Collection allocation
Hi, *** Question: What are all the possible ways to allocate and deallocate memory through the Garbage Collector? *** Context: I am parallelizing GCC internals and I am facing problems with the GCC Garbage Collector, and therefore I need to make it threadsafe to continue with the project. Currently, I want to do a palliative solution to this, which is locking a mutex every time a chunk of memory is allocated or deallocated. For this, I need to know all the possibilities to allocate and deallocate memory and lock/unlock the mutex there. As far as I have seen, there are the macros XALLOC, XNEW, XNEWVEC... defined in libiberty.h which are called everywhere in GCC, but I don't know if these are the only ways to allocate memory in GCC through the Garbage Collector. Thank you for your support, Giuliano.
Re: Threadsafe Garbage Collection allocation
On 6/28/19 2:48 PM, Giuliano Belinassi wrote: > Hi, > > *** > Question: What are all the possible ways to allocate and deallocate memory > through the Garbage Collector? > *** > > Context: I am parallelizing GCC internals and I am facing problems with the > GCC > Garbage Collector, and therefore I need to make it threadsafe to continue with > the project. > > Currently, I want to do a palliative solution to this, which is locking a > mutex > every time a chunk of memory is allocated or deallocated. For this, I need to > know all the possibilities to allocate and deallocate memory and lock/unlock > the mutex there. > > As far as I have seen, there are the macros XALLOC, XNEW, XNEWVEC... defined > in > libiberty.h which are called everywhere in GCC, but I don't know if these are > the only ways to allocate memory in GCC through the Garbage Collector. Those allocate via malloc, not the GC system. ggc_alloc is where you want to be looking. jeff
gcc-8-20190628 is now available
Snapshot gcc-8-20190628 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190628/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 272801 You'll find: gcc-8-20190628.tar.xzComplete GCC SHA256=5b1a5a543dffb9900784691eae85f8a8b17730097d92e9920291ffbe20ed4bbd SHA1=2b68ef3dd0e97549e4baa629ff73b2af98de544a Diffs from 8-20190621 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Threadsafe Garbage Collection allocation
On June 28, 2019 10:48:51 PM GMT+02:00, Giuliano Belinassi wrote: >Hi, > >*** >Question: What are all the possible ways to allocate and deallocate >memory >through the Garbage Collector? >*** > >Context: I am parallelizing GCC internals and I am facing problems with >the GCC >Garbage Collector, and therefore I need to make it threadsafe to >continue with >the project. > >Currently, I want to do a palliative solution to this, which is locking >a mutex >every time a chunk of memory is allocated or deallocated. For this, I >need to >know all the possibilities to allocate and deallocate memory and >lock/unlock >the mutex there. > >As far as I have seen, there are the macros XALLOC, XNEW, XNEWVEC... >defined in >libiberty.h which are called everywhere in GCC, but I don't know if >these are >the only ways to allocate memory in GCC through the Garbage Collector. GC allocation will eventually call ggc_alloc_internal and manual freeing ggc_free. Collection goes via ggc_collect and is done only at specific points triggered from the pass manager. Richard. >Thank you for your support, >Giuliano.
