[debug-early] reuse variable DIEs and fix their context

[Richard Biener]

On Tue, Sep 9, 2014 at 2:00 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
> On 09/05/14 02:00, Richard Biener wrote:
>
> [jason: C++ questions throughout.]
>
>> 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:
>
>
>> 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.
>
>
> This looks like a rat's nest :(.
>
> Interestingly, most non-C/C++ languages are well behaved, and use the
> generic write_global_declarations() function.  Ada even goes as far as
> calling debug_hooks->global_decl() before the compilation proper and then
> once again after the compilation has finished (like we're planning on
> doing).  Java, which you thought was horrible, mostly just calls the generic
> write_global_declarations().  C++ is a different story...
>
> It seems to me that C++ is the most complicated of the FE's when it comes to
> LANG_HOOKS_WRITE_GLOBALS.  Most annoyingly, it does many things *after* it
> has called finalize_compilation_unit (creating VTV constructors, calling
> check_global_declarations on pending_statics, building Java method aliases,
> etc etc).  See cp_write_global_declarations() for everything after
> finalize_compilation_unit).

Yeah, it was the Java method aliases building I remember (I tried before
VTV materialized) ;)   So I falsely blamed Java - it's only remotely Javas
fault ... ;)

> What I have in mind is:
>
> 1. Move the FE specific things that come before the call to
> finalize_compilation_unit currently in each LANG_HOOKS_WRITE_GLOBALS, into
> the FE proper (lang_hooks.parse_file).  This may or may not mean calling
> {wrapup,check}_global_declarations directly from the FEs since some FE's
> call these in a sufficiently different order to merit everyone doing their
> own thing (not sure though).
>
> 2. Generate debug information by gathering the list of globals with
> lang_hooks.decls.getdecls (??) and then doing
> debug_hooks->early_global_decl() as discussed.

Or move that also to lang_hooks.parse_file?  ISTR lang_hooks.decls.getdecls
is sort of an "alternative" hook to write_global_declarations that is only
used by the generic implementation of write_global_declarations.

So if we move everything else but calling debug_hooks->early_global_decl ()
out of the write_global_declarations langhook then we could indeed
remove that hook and implement getdecls everywhere.

I suppose one of the hooks should go in the end.

> 2. Call finalize_compilation_unit() directly from compile_file().

Great!

> 3. Call some (new) hook for C++ stuff after finalize_compilation_unit (???).

Or fix the C++ stuff to work properly in a symtab way?  I suppose as
an intermediate step adding a new langhook for this on the branch is ok
but I'd rather not get that merged into trunk.

Maybe Jason can help cleaning this up.

> 4. FOR_EACH_DEFINED_SYMBOL (node)
>      debug_hooks->late_global_decl (node->decl)
>
>    as suggested.
>
> The wildcard here is C++.  Shall we create a hook for post
> finalize_compilation_unit() but pre late debug dumping (item 3 above)? Or
> can we move most of the post finalize_compilation_unit() stuff in C++ before
> it, thus into the FE proper?  Also, disturbingly C++ calls
> check_global_declarations() after finalize_compilation_unit (a couple times
> actually).
>
> I think if we can get C++ to work, everything else basically falls into
> place... even Ada and Go ;-).

I hope that C++ can be "fixed" to do things in proper order and not
behind symtabs back.

For the branch to be able to move forward we can certainly add some
hooks temporarily.

Or disable the Java/VTV stuff for the time being.  I don't remember
running into the check_global_declarations () issue (or what that does).

Jason?

Tahnks,
Richard.

> Comments highly welcome.
> Aldy