On Wed, May 6, 2015 at 12:33 AM, Aldy Hernandez <al...@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?
> 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.
> Shortly after the merge I'll work on a pass to prune unused decl DIEs as
> we're presently creating more DIEs than mainline. This was expected, and if
> I understood Jason correctly, it is ok to work on this post-merge. However,
> even without such a pass, the .debug_info size difference is reasonable:
>
> gcc/* (except testsuite):
> Total .debug_info size for [debug-early]: 91081591.00
> Total .debug_info size for [mainline]: 84777565.00
> Total change: 7.44%
>
> libstdc++-v3/* (except testsuite):
> Total .debug_info size for [debug-early]: 5173014.00
> Total .debug_info size for [mainline]: 5044971.00
> Total change: 2.54%
>
> x86_64-unknown-linux-gnu/*
> Total .debug_info size for [debug-early]: 5893131.00
> Total .debug_info size for [mainline]: 5694176.00
> Total change: 3.49%
>
> The above stats are for "size -A <something> | grep debug_info...".
>
> Within gcc there were a handful of files that were significantly bigger
> (twice as much), and at least the 3-4 I investigated were all due to extra
> unused DIEs that will be handled by a DECL DIE optimization pass.
> Specifically, there are cases where external variables have their DIEs
> generated, because we cannot look at TREE_USED within early dwarf. Stuff
> like this will get a debug info (which is not terribly bad IMO):
>
> struct somestruct { int somefield; };
> extern struct somestruct *sometable;
>
> The other common scenario is the ICF pass which will mark hunks as
> undebuggable late in the compilation process (by setting DECL_IGNORED_P)--
> actually any pass calling expand_hunk(). This happens for something like
> c-family/stub-objc.c which have multiple identical stubs and get folded into
> one function.
>
> So...all in all, the .debug_info increase is within what was expected when
> we started this project (3-7%). Actually, I'm pleasantly surprised it's not
> 10-15%. I expect to get this down significantly in short time.
>
> 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.
> And of course... I'm not going anywhere. Unfortunately, I'm not even going
> on vacation... so I'm here to fix the fallout ;-).
Good to know.
Thanks,
Richard.
> Aldy
