This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 2/2] DWARF: make it possible to emit debug info for declarations only
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Pierre-Marie de Rodat <derodat at adacore dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 20 Jun 2017 14:16:06 +0200
- Subject: Re: [PATCH 2/2] DWARF: make it possible to emit debug info for declarations only
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <CAFiYyc3NfKn+3BshKjhwH-U31TkyUEeJ62BezkF0rkbTvshQbQ@mail.gmail.com> <email@example.com> <CAFiYyc3A+NU6d-ZtGqO8NKHa7nwJ0S-Ov4JT2TwMc=6PErf0xQ@mail.gmail.com> <firstname.lastname@example.org> <email@example.com>
On Fri, Jun 16, 2017 at 6:35 PM, Pierre-Marie de Rodat
> On 05/31/2017 11:08 AM, Pierre-Marie de Rodat wrote:
>> On 05/31/2017 09:34 AM, Richard Biener wrote:
>>> Actually for the bigger picture I'd refactor
>>> rest_of_decl_compilation, not calling it from the frontends but
>>> rely on finalize_decl/function. The missing part would then be
>>> calling the dwarf hook which should eventually be done at some of
>>> the places the frontends now call rest_of_decl_compliation.
> I put some thought about this, but I suppose I don’t yet understand well
> enough the relation between what rest_of_decl_compilation and
> finalize_decl/function do. So I’ve tried to go half-way: I moved the
> “specification?” guard from the DWARF back-end to callers of the
> early_global_decl hook. In the end, this yielded a very small middle-end
> change: almost all hook calls in front-ends are for variables or namespaces,
> not for functions.
>>> But for an easier way (you might still explore the above ;)) just remove
>>> the guards from dwarf2out.c and handle it more like types that we
>>> prune if they end up being unused (OTOH I guess we don't refer to
>>> the decl DIEs from "calls" because not all calls are refered to with
>>> standard DWARF -- the GNU callsite stuff refers them I think but those
>>> get generated too late).
>>> That said, when early_finish is called the cgraph and IPA references
>>> exists and thus you can
>>> sort-of see which functions are "used".
>> Ok, thanks. I’ll give a try to the first option, then. :-)
> I finally decided not to implement this scheme, as it does not give the same
> results for the case in Ada that motivated this change: it would generate
> potentially one DIE per “calling unit” per called function, which is quite
> suboptimal compared to one DIE per subprogram definition or subprogram
> import. This would look like a debug info bloat for debatable gain.
> So here’s an updated patch, without the new debug hook. It boostrapped and
> regtested fine on x86_64-linux. After this change, I observed an increase
> * an increase of ~22KB for gnat1 (base is 210MB);
> * a decrease (?) of ~3KB for cc1 (base is 197MB);
> * a similar decrease of 3KB for cc1plus (base is 220MB).
> Ok to commit?
Nice. This looks ok.
I'm mildy curious about the deecrease of debuginfo size for cc1 -- did
you spot anything obvious there?
I suspect Fortran wants to do sth similar as Ada for imported modules.
> Pierre-Marie de Rodat