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

Richard Biener richard.guenther@gmail.com
Fri Dec 19 11:20:00 GMT 2014


On Thu, Dec 18, 2014 at 8:23 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
> Hi Jason.
>
> It's embarrassing that I just got to this now.  I hope you don't repay the
> favor and take as long responding to me :(.
>
> On 09/12/14 08:15, Jason Merrill wrote:
>>
>> On 09/11/2014 08:51 PM, Aldy Hernandez wrote:
>
>
>>>    /* Generate hidden aliases for Java.  */
>>> -  if (candidates)
>>> +  if (java_hidden_aliases)
>>>      {
>>> -      build_java_method_aliases (candidates);
>>> -      delete candidates;
>>> +      build_java_method_aliases (java_hidden_aliases);
>>> +      delete java_hidden_aliases;
>>>      }
>>
>>
>> Didn't it work to move this before finalize?  I think the VTV stuff is
>> all that really needs to come after it, and that can move out of the
>> front end if this hook is a problem (which I don't really think it is).
>
>
> I can't move the call to build_java_method_aliases until the compilation
> proper has run because said function iterates through all the functions with
> FOR_EACH_FUNCTION, and the set of available functions at parse time and
> after the optimization passes are quite different, presumably because we've
> pruned all the unused functions.
>
> If I move the call to build_java_method_aliases before the optimization
> passes, we end up emitting many more hidden aliases which cause
> handle_alias_pairs() in cgraphunit.c to bark with:
>
> error: 'void _ZGAN8__JArrayC4Ev()' aliased to external symbol
> '_ZN8__JArrayC4Ev'
>
> So we either leave building Java method aliases after the optimization
> passes, or we somehow tighten the candidate selection in
> collect_candidates_for_java_method_aliases():
>
>       if (DECL_CLASS_SCOPE_P (fndecl)
>           && TYPE_FOR_JAVA (DECL_CONTEXT (fndecl))
>           && TARGET_USE_LOCAL_THUNK_ALIAS_P (fndecl))
>
> What do you suggest?

Yeah, I've told you that this is a major blocker I couldn't resolve the last
time I tried to move things.

IMHO this Java method aliases needs to be made cgraph-aware somehow,
thus we need to build the aliases as proper aliases during candidate
collection but somehow mark them reclaimable by the cgraph code
(builtding the aliases is only done if TREE_ASM_WRITTEN).

Honza may have an idea here?

Richard.

> I can, however, move all the other non-VTV stuff to the parser in a
> subsequent patch, while you respond to this query.
>
> Thanks.
> Aldy



More information about the Gcc-patches mailing list