Re: Merging debug-early work?

[Aldy Hernandez <aldyh at redhat dot com>]

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