This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH 2/2] DWARF: make it possible to emit debug info for declarations only


On Fri, Jun 16, 2017 at 6:35 PM, Pierre-Marie de Rodat
<derodat@adacore.com> wrote:
> 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
> of:
>
>   * 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.

Thanks,
Richard.

> --
> Pierre-Marie de Rodat


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