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?
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
