public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Pierre-Marie de Rodat <derodat@adacore.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 2/2] DWARF: make it possible to emit debug info for declarations only
Date: Wed, 31 May 2017 07:37:00 -0000	[thread overview]
Message-ID: <CAFiYyc3A+NU6d-ZtGqO8NKHa7nwJ0S-Ov4JT2TwMc=6PErf0xQ@mail.gmail.com> (raw)
In-Reply-To: <e1c06a8e-7a5f-9b16-8ef2-7aac1ee538ec@adacore.com>

On Tue, May 30, 2017 at 5:47 PM, Pierre-Marie de Rodat
<derodat@adacore.com> wrote:
> Thank you for your review, Richard.
>
> On 05/30/2017 01:59 PM, Richard Biener wrote:
>>
>> I think the issue is unfortunate in the C frontend as well.  So I believe
>> we can
>> go without a new langhook and instead make sure
>> dwarf2out_early_global_decl
>> is not called for uninteresting decls (which means eventually pushing the
>> call(s) of that hook more towards the FEs).
>
>
> It is called by rest_of_decl_compilation, which seems itself to be called a
> lot on FUNCTION_DECL nodes. Before I dive into this consequent change: this
> would lead for instance to add a parameter to rest_of_compilation to control
> whether it must call the early_global_decl hook, and then to update all
> callers accordingly. Is this what you actually have in mind?

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.

>
>> For C/C++ it would be reasonable to output debug info for external
>> declarations
>> that end up being used for example.
>
>
> I guess that could be done indeed. :-)

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".

Richard.

> --
> Pierre-Marie de Rodat

  reply	other threads:[~2017-05-31  7:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-29  7:50 [PATCH 1/2] gimplify_modify_expr: avoid DECL_DEBUG_EXPR links across functions Pierre-Marie de Rodat
2017-05-29  8:05 ` [PATCH 2/2] DWARF: make it possible to emit debug info for declarations only Pierre-Marie de Rodat
2017-05-29 13:39   ` Pierre-Marie de Rodat
2017-05-30 12:11   ` Richard Biener
2017-05-30 15:51     ` Pierre-Marie de Rodat
2017-05-31  7:37       ` Richard Biener [this message]
2017-05-31  9:12         ` Pierre-Marie de Rodat
2017-06-16 16:35           ` Pierre-Marie de Rodat
2017-06-20 12:16             ` Richard Biener
2017-06-20 14:34               ` Pierre-Marie de Rodat
2017-06-21  7:11                 ` Richard Biener
2017-06-21 11:25                   ` Pierre-Marie de Rodat
2017-05-30 11:59 ` [PATCH 1/2] gimplify_modify_expr: avoid DECL_DEBUG_EXPR links across functions Richard Biener
2017-05-30 15:35   ` Pierre-Marie de Rodat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFiYyc3A+NU6d-ZtGqO8NKHa7nwJ0S-Ov4JT2TwMc=6PErf0xQ@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=derodat@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).