On Thu, 30 Jul 2020, Jakub Jelinek wrote:
> On Thu, Jul 30, 2020 at 11:55:19AM +0200, Richard Biener wrote:
> > For cc1 this affects debug information size as follows:
> >
> > VM SIZE FILE SIZE
> > ++++++++++++++ GROWING ++++++++++++++
> > [ = ] 0 .debug_info +1.63Mi +1.3%
> > [ = ] 0 .debug_str +263Ki +3.4%
> > [ = ] 0 .debug_abbrev +101Ki +4.9%
> > [ = ] 0 .debug_line +5.71Ki +0.0%
> > +44% +16 [Unmapped] +48 +1.2%
> >
> > -------------- SHRINKING --------------
> > [ = ] 0 .debug_loc -213 -0.0%
> > -0.0% -48 .text -48 -0.0%
> > [ = ] 0 .debug_ranges -16 -0.0%
> >
> > -0.0% -32 TOTAL +1.99Mi +0.6%
> >
> > and DWARF compression via DWZ can only shave off minor bits
> > here.
>
> I'm surprised DWZ doesn't shave off more, the prototypes in
> the different TUs should be the same and therefore mergeable.
Yeah, DWZ shaves off 60% of the .debug_info overhead, but due
to the size of cc1 I have not tried figuring out what the difference
in the end will be.
> What could help a little if DWZ is able to merge the prototypes with
> definition DIE (verify that the type is the same and there is no information
> the definition doesn't have appart from DW_AT_external).
DWZ could split out a shareable specification DIE from definition
DIEs and use DW_AT_specification. When we bring declarations into
scope elsewhere we have to avoid refering to definitions there.
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> >
> > OK for trunk and backports?
>
> I'd go with it for trunk and 10.2.1 now and consider further backports
> later. Maybe even defer the 10.2.1 backport for two weeks.
So testing revealed I have to be more careful what nodes I create
DIEs for. For example for g++.dg/debug/dwarf2/cdtor-1.C we'd now
end up with DIEs for all of the DTOR aliases (and IIRC aliases are
not subject to unused removal, nor unused members of a comdat group).
In particular guarding the nodes with
if (!cnode->alias && !cnode->thunk.thunk_p
&& !fndecl_built_in_p (cnode->decl))
seems to fix the few regressions observed. I'm retesting fully with
that.
Richard.
