public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: Jason Merrill <jason@redhat.com>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [debug-early] reuse variable DIEs and fix their context
Date: Fri, 05 Sep 2014 09:00:00 -0000	[thread overview]
Message-ID: <CAFiYyc2FYcrRQ7qF4c6jmSHHasA11JiO6kVXWBXOChsGQ9f6eQ@mail.gmail.com> (raw)
In-Reply-To: <5409220E.6070100@redhat.com>

On Fri, Sep 5, 2014 at 4:38 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
> On 09/04/14 03:42, Richard Biener wrote:
>>
>> On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
>
>
>> Flow-wise I still want to move hand-off to the cgraph code to toplev.c,
>> out from the FEs final_write_gloabals hook:
>>
>>    /* This must also call finalize_compilation_unit.  */
>>    lang_hooks.decls.final_write_globals ();
>>
>> that would make clearer how control flows.
>
>
> Neat.  I like it.
>
>> I'd also rather split the hook into two ... (and call the 2nd non-early
>> phase hook from where we output the code).  What does that phase
>> output for global decls anyway?
>
>
> This is also a very good idea, and it makes the intent clearer.
>
>> Otherwise looks like a good incremental improvement to me.
>
>
> Since we're pretty much on the same page, I've committed this revision you
> just looked at, so we can talk about the changes you mention above
> separately, namely:
>
> a) Divorcing final_write_globals and finalize_compilation.
> b) Splitting the global_decl hook into two.
>
> So this is what I have in mind (patch attached).  I'd like to split
> LANG_HOOKS_WRITE_GLOBALS in favor of LANG_HOOKS_{EARLY,LATE}_WRITE_GLOBALS,
> as well as splitting the global_decl debug hook into
> {early,late}_global_decl.  I've commented things throughout to make it very
> clear what we're getting at.

I meant that LATE_WRITE_GLOBALS shouldn't be a langhook
at all but instead the middle-end should be in control of that and
implement it in a language independent way.  After all this will be
called from LTO LTRANS phase.

> I chose to dispense with the old names to make it very clear what the hook
> should do, and to make sure I didn't miss any places.
>
> Toplev will now look much cleaner:
>
> +  /* Emit early debugging information as well as globals.  */
> +  timevar_start (TV_PHASE_DEFERRED);
> +  lang_hooks.decls.early_write_globals ();
> +  timevar_stop (TV_PHASE_DEFERRED);
> +
> +  /* We're done parsing; proceed to optimize and emit assembly.  */
> +  timevar_start (TV_PHASE_OPT_GEN);
> +  symtab->finalize_compilation_unit ();
> +  timevar_stop (TV_PHASE_OPT_GEN);
> +
> +  /* Amend any debugging information generated previously.  */
> +  timevar_start (TV_PHASE_DBGINFO);
> +  lang_hooks.decls.late_write_globals ();
> +  timevar_stop (TV_PHASE_DBGINFO);
>
> Preeeeety... if I do say so myself.

Yeah - apart from that langhook issue for late_write_globals ;)

> The attached patch is untested, and will fail miserably on anything but C
> (lto, c++, etc).  But it shows how I'd like to approach this.
>
> Would you bless this approach, so I can continue with the other languages
> and LTO?

Be prepared to meet some fun with Java and moving finalize_compilation_unit
out (I remember trying that at some point).

Otherwise it would be nice if you can implement late_write_globals by
simply walking the symbol table with sth like

  FOR_EACH_DEFINED_SYMBOL (node)
     debug_hooks->late_global_decl (node->decl);

well - of course it will likely not be _that_ simple.  And eventually it's
better to do this from where we have done the output (in varasm.c
for variables and somewhere in final.c for functions), but let's try
that FOR_EACH as it looks so simple ;)

Richard.

> As usual, thanks for your feedback.
> Aldy

  reply	other threads:[~2014-09-05  9:00 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27  2:43 Aldy Hernandez
2014-08-28 13:58 ` Richard Biener
2014-08-28 17:35   ` Aldy Hernandez
2014-08-28 18:01     ` Jason Merrill
2014-08-28 19:13       ` Richard Biener
2014-08-28 20:14         ` Jason Merrill
2014-08-29  9:09           ` Richard Biener
2014-09-03 17:55       ` Aldy Hernandez
2014-09-04 10:42         ` Richard Biener
2014-09-05  2:38           ` Aldy Hernandez
2014-09-05  9:00             ` Richard Biener [this message]
2014-09-09  0:01               ` Aldy Hernandez
2014-09-09  9:16                 ` Richard Biener
2014-09-12  0:51                   ` Aldy Hernandez
2014-09-12  8:13                     ` Richard Biener
2014-09-12 15:15                     ` Jason Merrill
2014-09-12 17:11                       ` Aldy Hernandez
2014-09-12 17:33                         ` Jason Merrill
2014-09-12 17:48                           ` Aldy Hernandez
2014-09-12 17:56                             ` Jason Merrill
2014-09-16 15:49                               ` Aldy Hernandez
2014-09-15  9:32                         ` Richard Biener
2014-09-15 18:46                           ` Jason Merrill
2014-12-18 19:26                       ` Aldy Hernandez
2014-12-19 11:20                         ` Richard Biener
2014-12-19 18:58                           ` Jan Hubicka
2014-12-19 19:01                             ` Jan Hubicka
2014-12-19 19:02                               ` Aldy Hernandez
2014-12-19 19:31                                 ` Jason Merrill
2014-12-19 19:50                                   ` Jan Hubicka
2014-12-20 10:09                                   ` Aldy Hernandez
2015-01-08 12:24                                     ` Richard Biener
2014-12-19 19:03                             ` Aldy Hernandez
2014-09-04 17:53         ` H.J. Lu
2014-09-04 17:54           ` Aldy Hernandez
2014-09-04 18:23             ` Richard Biener
2014-09-04 18:35               ` Aldy Hernandez
2014-09-04 18:38                 ` Christophe Lyon
2014-09-04 19:42                 ` Jan-Benedict Glaw
2015-01-08 15:20 Aldy Hernandez

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=CAFiYyc2FYcrRQ7qF4c6jmSHHasA11JiO6kVXWBXOChsGQ9f6eQ@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /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).