This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Merging debug-early work?

On 05/06/2015 04:22 AM, Richard Biener wrote:
On Wed, May 6, 2015 at 12:33 AM, Aldy Hernandez <> wrote:

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?


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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]