Re: Mysterious decision in combine
On Thu, Mar 17, 2016 at 01:22:04PM -0700, Richard Henderson wrote: > On 03/16/2016 11:35 PM, Dominik Vogt wrote: > > How does combine get this idea (it's the only match in the > > function)? > > > > Trying 7 -> 12: > > Successfully matched this instruction: > > (set (reg/i:DI 2 %r2) > > (and:DI (subreg:DI (reg:SI 64) 0) > > (const_int 4294901775 [0x000f]))) > > allowing combination of insns 7 and 12 > > >From the recorded nonzero_bits. Understood so far. Now combine tries to combine (parallel [ (set (reg:SI 64) (and:SI (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32]) (const_int -65521 [0x000f]))) (clobber (reg:CC 33 %cc)) ]) and (set (reg:DI 65) (zero_extend:DI (reg:SI 64))) Why does it drop the "parallel" and "clobber" in the combination; is there a way to force combine to keep that? Trying 6 -> 7: Failed to match this instruction: (set (reg:DI 65) (and:DI (subreg:DI (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32]) 0) (const_int 4294901775 [0x000f]))) (Because all "and" instructions on s390 clobber the CC, this pattern does not match anything without the clobber.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany
Re: Aggressive load in gcc when accessing escaped pointer?
Hi, On Sat, 19 Mar 2016, Cy Cheng wrote: > But I don't understand why &c - 8 is invalid? Which rule in C99 it volatile? &x points to the start of object x, and &x - something (something != 0) points outside object x. 'c' was a complete object, so &c-8 points outside any object, hence the formation of that pointer is already invalid (as is its dereference). Ciao, Michael.
Re: Leaking bitmap data in ree.c?
On 03/20/2016 09:24 PM, Trevor Saunders wrote: On Fri, Mar 18, 2016 at 01:18:16PM -0600, Jeff Law wrote: Is it just me, or does find_removable_extensions leak bitmap data for INIT, KILL, GEN and TMP? It calls bitmap_initialize on all of them, but never clears the bitmaps... Am I missing something? See this lovely comment for bitmap_initialize_stat () which is macroed to bitmap_initialize () /* Initialize a bitmap header. OBSTACK indicates the bitmap obstack to allocate from, NULL for GC'd bitmap. */ So I think the elements for those bitmaps are just getting allocated on the gc heap, and everything is correct though of course it would be nice to stop using the gc there. Yea, but it's kindof silly to force the ggc system to handle this. At the least a bitmap_clear would return the bitmap elements to the bitmap element cache (which should also be more efficient for the ggc system) I'll resist the urge for now to apply RAII principles in this code, but that'd probably a much cleaner way to think about the problem in general. jeff
Re: Leaking bitmap data in ree.c?
On 03/21/2016 11:15 AM, Trevor Saunders wrote: I'll resist the urge for now to apply RAII principles in this code, but that'd probably a much cleaner way to think about the problem in general. I worked on a couple attempts to c++ify bitmaps a while back, but never finished any of them, but I could probably publish what I did in case someone wants to pick that up for gcc 7. Can't hurt. FWIW, bitmaps are low level and independent of trees, rtl, etc that we ought to (in theory) be able to class-ify them and build a real unit testing framework for them. jeff
Re: Leaking bitmap data in ree.c?
On Mon, 2016-03-21 at 11:13 -0600, Jeff Law wrote: > On 03/21/2016 11:15 AM, Trevor Saunders wrote: > > > > > I'll resist the urge for now to apply RAII principles in this > > > code, but > > > that'd probably a much cleaner way to think about the problem in > > > general. > > > > I worked on a couple attempts to c++ify bitmaps a while back, but > > never > > finished any of them, but I could probably publish what I did in > > case > > someone wants to pick that up for gcc 7. > Can't hurt. > > FWIW, bitmaps are low level and independent of trees, rtl, etc that > we > ought to (in theory) be able to class-ify them and build a real unit > testing framework for them. Something like: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02371.html ?
Re: Leaking bitmap data in ree.c?
On Mon, Mar 21, 2016 at 10:42:18AM -0600, Jeff Law wrote: > On 03/20/2016 09:24 PM, Trevor Saunders wrote: > >On Fri, Mar 18, 2016 at 01:18:16PM -0600, Jeff Law wrote: > >> > >>Is it just me, or does find_removable_extensions leak bitmap data for INIT, > >>KILL, GEN and TMP? > >> > >>It calls bitmap_initialize on all of them, but never clears the bitmaps... > >> > >>Am I missing something? > > > >See this lovely comment for bitmap_initialize_stat () which is macroed > >to bitmap_initialize () > > > >/* Initialize a bitmap header. OBSTACK indicates the bitmap obstack > >to allocate from, NULL for GC'd bitmap. */ > > > >So I think the elements for those bitmaps are just getting allocated on > >the gc heap, and everything is correct though of course it would be nice > >to stop using the gc there. > Yea, but it's kindof silly to force the ggc system to handle this. At the > least a bitmap_clear would return the bitmap elements to the bitmap element > cache (which should also be more efficient for the ggc system) yeah > I'll resist the urge for now to apply RAII principles in this code, but > that'd probably a much cleaner way to think about the problem in general. I worked on a couple attempts to c++ify bitmaps a while back, but never finished any of them, but I could probably publish what I did in case someone wants to pick that up for gcc 7. Trev > > jeff
Re: Leaking bitmap data in ree.c?
On 03/21/2016 11:16 AM, David Malcolm wrote: On Mon, 2016-03-21 at 11:13 -0600, Jeff Law wrote: On 03/21/2016 11:15 AM, Trevor Saunders wrote: I'll resist the urge for now to apply RAII principles in this code, but that'd probably a much cleaner way to think about the problem in general. I worked on a couple attempts to c++ify bitmaps a while back, but never finished any of them, but I could probably publish what I did in case someone wants to pick that up for gcc 7. Can't hurt. FWIW, bitmaps are low level and independent of trees, rtl, etc that we ought to (in theory) be able to class-ify them and build a real unit testing framework for them. Something like: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02371.html Like that, or complete instantiation outside GCC. jeff
Re: [GCC Wiki] Update of "DebugFission" by CaryCoutant
We're in the final stages of finalizing the DWARF v5 spec, which will
include the Fission extensions. When that's done, we'll start
converting GCC and gold over to use the official DWARF features rather
than the GNU extensions.
>> + The "Fission" project was started in response to the problems caused by
>> huge amounts of debug information in large applications. By splitting the
>> debug information into two parts at compile time -- one part that remains in
>> the .o file and another part that is written to a parallel .dwo ("DWARF
>> object") file -- we can reduce the total size of the object files processed
>> by the linker.
>
> Yay, a quite noticeable link-time speedup! \o/
Good!
>> + Fission is implemented in GCC 4.7, and requires support from recent
>> versions of objcopy and the gold linker.
>
> Is my understanding correct that the gold linker is not actually a
> requirement -- at least nowadays? In my (very limited, so far) testing,
> this also seems to work with ld.bfd. (I do see objcopy's --extract-dwo
> and --split-dwo options being used in gcc/gcc.c:ASM_FINAL_SPEC, so I
> suspect that's what "recent versions of objcopy" hints at?)
Yes, that's what we need from objcopy.
The reason gold is needed is for the --gdb-index option. Without the
.gdb_index section, gdb has to load all the .dwo files at startup so
that it knows all the symbols; with the .gdb_index section, it can
find symbols in the index and load the necessary .dwo file(s) on
demand. On a large project, I'd still expect absence of an index to be
painful enough that I'd leave that requirement in the wiki.
>> + Use the {{{-gsplit-dwarf}}} option to enable the generation of split DWARF
>> at compile time. This option must be used in conjunction with {{{-c}}};
>> Fission cannot be used when compiling and linking in the same step.
>
> According to the following -- admittedly very minimal -- testing, this is
> not actually (no longer?) true?
>
> $ [gcc] [...] -gsplit-dwarf
> $ ls *.dwo
> ccF9JYjE.dwo subroutines.dwo
> $ gdb -q a.out
> Reading symbols from a.out...done.
> (gdb) list main
> [...]
> (gdb) quit
> $ rm *.dwo
> $ gdb -q a.out
> Reading symbols from a.out...
> warning: Could not find DWO CU subroutines.dwo(0x2d85cdd539df6900)
> referenced by CU at offset 0x0 [in module [...]/a.out]
>
> warning: Could not find DWO CU ccF9JYjE.dwo(0xa6936555a636518) referenced
> by CU at offset 0x35 [in module [...]/a.out]
> done.
> (gdb) list main
> warning: Could not find DWO CU subroutines.dwo(0x2d85cdd539df6900)
> referenced by CU at offset 0x0 [in module [...]/a.out]
>
> Have I been testing the wrong thing?
Hmmm, I think the problem here is that the .dwo files corresponding to
the temporary .o files will never get cleaned up, and might even get
overwritten unpredictably. It's just not a fully-supported path. I may
have forgotten some other issues. I may have also been expecting them
to get automatically cleaned up when the .o was removed.
>> + Use the gold linker's {{{--gdb-index}}} option ({{{-Wl,--gdb-index}}} when
>> linking with gcc or g++) at link time to create the .gdb_index section that
>> allows GDB to locate and read the .dwo files as it needs them.
>
> Unless told otherwise, I'll re-word that to the effect that gold, and
> usage of its --gdb-index option are optional.
Maybe "highly recommended" would be better.
-cary
Re: [gimplefe] [gsoc16] Gimple Front End Project
Hi!
How exactly can we achieve start stop compilation on specific pass (ie
run single pass on input)?
eg. $cgimple -ftree-copyrename foo.c
should produce optimization result of -ftree-copyrename pass on foo.c input
On 21 March 2016 at 09:05, Trevor Saunders wrote:
> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>> Hi!
>>
>> Sorry for the late reply.
>>
>> I was observing gimple dumps and my initial findings are, to parse
>> gimple, we have to add support for following components to C FE
>>
>> *basic blocks
>
> I'd think you can probably make these enough like C labels that you
> don't need to do anything special in the C fe to parse these. Just
> removing the < and > gets you pretty close is that it?
>
>> *gimple labels and goto
>
> Similar I think.
>
>> *gimple phi functions
>> iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>
> yesI think you need to add something here. I think you can do it as a
> builtin type function that expects its arguments to be labels or names
> of variables.
>
>> *gimple switch
>> switch (a_1) , case 1: , case 2: >
>
> I'd think we could make this more C like too.
>
>> *gimple exception handling
>
> yeah, though note exceptions are lowered pretty quickly so supporting
> them with the explicit exception syntax probably isn't particularly
> important.
>
>> *openmp functions like
>> main._omp_fn.0 (void * .omp_data_i)
>
> I'd think you'd want to change the duping of this some to make it easier
> to tell from struct.some.member.
>
>> Please correct me if I am wrong. Also point out if I am missing anything
>
> I think you might need to do something about variable names?
>
> Trev
>
>>
>>
>>
>>
>> On 18 March 2016 at 14:53, Richard Biener wrote:
>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>> > wrote:
>> >> On 15 March 2016 at 20:46, Richard Biener
>> >> wrote:
>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>
>> > Then I'd like to be able to re-construct SSA without jumping through
>> > hoops (usually you can get close but if you require copies propagated
>> > in
>> > a special way you are basically lost for example).
>> >
>> > Thus my proposal to make the GSoC student attack the unit-testing
>> > problem by doing modifications to the pass manager and "extending" an
>> > existing frontend (C for simplicity).
>>
>> I think it's wrong to try to shoehorn the gimple FE into the C FE. C is
>> fundamentally different from gimple and you'd have to sprinkle
>> gimple_dialect_p() all over the place, and maintaining that while
>> developing future C improvements will turn out to be much work. Some
>> differences of C and gimple:
>>
>> * C has recursive expressions, gimple is n-op stmts, no expressions at
>> all
>> * C has type promotions, gimple is explicit
>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>> * C has scopes, gimple doesn't (well, global and local only), i.e.
>> symbol
>> lookup is much more complicated
>> * C doesn't have exceptions
>> * C doesn't have class types, gimple has
>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>> * C doesn't have self-referential types
>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>> gimplifier and again would feed gimple directly into the passes)
>>
>> I really don't think changing the C FE to accept gimple is a useful way
>> forward.
>> >>>
>> >>> So I am most worried about replicating all the complexity of types and
>> >>> decl
>> >>> parsing for the presumably nice and small function body parser.
>> >> Um would it be a good idea if we separate "gimple" functions from
>> >> regular C functions,
>> >> say by annotating the function definition with "gimple" attribute ?
>> >
>> > Yes, that was my idea.
>> >
>> >> A "gimple" function should contain only gimple stmts and not C.
>> >> eg:
>> >> __attribute__((gimple))
>> >> void foo(void)
>> >> {
>> >> // local decls/initializers in C
>> >> // GIMPLE body
>> >> }
>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>> >> is a GIMPLE function.
>> >
>> > Though instead of an attribute I would indeed use a new keyword (as you
>> > can't really ignore the attribute and it should be an error with compilers
>> > not knowing it). Thus sth like
>> >
>> > void foo (void)
>> > __GIMPLE {
>> > }
>> >
>> > as it's also kind-of a "definition" specifier rather than a
>> > declaration specifier.
>> >
>> >>
>> >> My intention is that we could reuse C FE for parsing types and decls
>> >> (which I suppose is the primary
>> >> motivation behind reusing C FE) and avoid mixing C statements with
>> >> GIMPLE by having a separate
>> >> GIMPLE parser for parsing GIMPLE functions.
>> >> (I suppose the GIMPLE function parser would
4.9 backport request
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 Would anyone mind backporting these two dependent bug fixes to 4.9?
Re: 4.9 backport request
On March 22, 2016 2:07:10 AM GMT+01:00, NightStrike wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709 >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 > >Would anyone mind backporting these two dependent bug fixes to 4.9? Both are not regressions there so no appropriate at this stage. Richard.
