Re: A question about java/lang.c:java_get_callee_fndecl.

[Andrew Haley <aph at redhat dot com>]

Steven Bosscher writes:
 > On Tuesday 22 March 2005 09:11, Andrew Haley wrote:
 > > Kazu Hirata writes:
 > >  > Hi,
 > >  >
 > >  > I see that the implementation of LANG_HOOKS_GET_CALLEE_FNDECL in Java
 > >  > always returns NULL (at least for the time being).
 > >  >
 > >  > static tree
 > >  > java_get_callee_fndecl (tree call_expr)
 > >  > {
 > >  >   tree method, table, element, atable_methods;
 > >  >
 > >  >   HOST_WIDE_INT index;
 > >  >
 > >  >   /* FIXME: This is disabled because we end up passing calls through
 > >  >      the PLT, and we do NOT want to do that.  */
 > >  >   return NULL;
 > >  >
 > >  >
 > >  >
 > >  >
 > >  > Is anybody planning to fix this?
 > >
 > > Yes.
 > >
 > > The problem is that I want to expose opportunities for inlining but I
 > > do not want calls to global functions to go through the PLT as
 > > required by C semantics.  To do that causes endless problems.
 > 
 > Ehm, inline how? We currently inline GIMPLE, but your langhook is
 > looking for FUNCTION_DECLs in something that is not GIMPLE.

That's right; it's disabled.

 > The langhook currently looks inside ARRAY_REFs right now.

No, it doesn't.  That's what it used to do but it's currently
disabled.

 > Apparently Java has calls of the form
 > CALL_EXPR<ARRAY_REF<array,index>, ....>, which is very much *not*
 > GIMPLE.

OK.

 > So if you enable the lang hook, you are either going to need a
 > GIMPLE extension (bad), or figure out some different way to
 > represent this kind of call such that the CALL_EXPR is proper
 > GIMPLE.

Sure, that's fine.

 > IMHO it is Bad Taste(tm) anyway if get_callee_fndecl must look in
 > language specific data structures even when it is call from language
 > independent parts of the compiler, like the tree optimizers.

The whole point of get_callee_fndecl is to look in language specific
data structures.

Andrew.