Merging debug-early work?

Aldy Hernandez aldyh@redhat.com
Thu May 7 15:29:00 GMT 2015


On 05/06/2015 04:22 AM, Richard Biener wrote:
> On Wed, May 6, 2015 at 12:33 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
>> Gentlemen!
>>
>> I believe I have done as much as is reasonable for a merge, but I'd like to
>> get your opinion before I post a huge patch to the list.
>>
>> The branch bootstraps with one regression in GCC
>> (gcc.dg/debug/dwarf2/stacked-qualified-types-3.c) and none for GDB.
>
> On which triplets?

	x86_64-unknown-linux-gnu
	powerpc-ibm-aix7.1.2.0
	powerpc64-unknown-linux-gnu
	aarch64-unknown-linux-gnu

So, two non x86 targets, and one non-x86 target that is also non-dwarf. 
  Two primary targets and two secondary targets.  For the record, the 
gdb testsuite was only run on x86_64-linux, everything else was just the 
usual GCC testing.

>
>> The GCC regression is a missed optimization while merging the common
>> denominator of a set of qualifiers for a type within a DIE.  For example, if
>> two types share "const volatile" (say "const volatile int" and "const
>> volatile char"), dwarf2out outputs things in the most efficient manner as to
>> share the maximum common type DIEs.  This is not working in the branch as
>> TYPE_MAIN_VARIANTs are not complete by the time early dwarf is run.  If it
>> is possible, I'd like to work on this one regression post-merge.  Not a big
>> deal if you disagree, but I'd prefer to postpone on this non crucial bit.
>>
>> A few caveats...
>>
>> Richi wants to play around with free-lang-data in the non LTO path.  I
>> haven't not done so, and it's left as an exercise to the reader :).
>
> Yeah - I'd also like the early/late paths in dwarf2out.c to be refactored
> to completely different functions (that is, not have a single function
> creating and/or annotating DIEs early and late but two - with the late
> one only doing the annotation work and only annotating with stuff
> we expect).  The branch already has accumulated quite some checks
> like "if DIE was created early..." and with the LTO prototype work I saw
> I'd only need to add (very?) much more of those.

That would be very much appreciated.  It is something I realized a bit 
too late.

>> Thoughts on moving forward?  Is the stacked qualifier regression a show
>> stopper?  Is the .debug_info size regression acceptable?
>
> I think both are acceptable if they are fixed in a reasonable time frame
> (before stage1 ends).  So I suggest to go forward with merging and send
> a nice patch-set.

Great.  Coming up...

Aldy



More information about the Gcc mailing list