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.
