On Thu, May 7, 2015 at 5:29 PM, Aldy Hernandez <al...@redhat.com> wrote: > On 05/06/2015 04:22 AM, Richard Biener wrote: >> >> 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? > > > 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.
Did you see if --with-build-config=bootstrap-lto still works? >> >>> 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. Yeah. The nice thing is that we already have an entry for the most sophisticated part - the function_decl debug-hook called from the appropriate place in final.c for functions we have output. Of course that simply maps to dwarf2out_decl right now, but it's a good start to prune stuff here by "inlining" stuff here an pruning obviously unnecessary (and harmful) stuff. What we are missing is a corresponding hook (well, that could be just late_gobal_decl ...) for global vars we output, called from the approriate place in varasm.c (assemble_variable? called from varpool assemble_decl via symtab output_variables). At least hook-wise that would be the clean solution for the late dwarf stage. While doing the LTO work I wondered why you have the late_global_decl loop in toplev.c:compile_file at all (well, maybe due to the missing one for global vars output). At least for function decls we should have covered everything by that point. Early debug seems to be enforced at finalize-compilation-unit time, but only for function decls - I wonder why not as well for global vars (and why the odd !decl_function_context check is there for functions). That said, this and the code in rest_of_decl_compilation should best be merged to a single place (preferably rest_of_decl_compilation). >>> 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... Thanks. Richard. > Aldy
