[LLVMdev] Re: Newbie questions

[Alkis Evlogimenos]

On 29 Apr 2006 20:38:58 -0600, Tom Tromey <tromey at redhat.com> wrote:
> >>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes:
>
> >> In the JIT, devirtualization looks doable, though somewhat fiddly.  At
> >> least, that is true for straightforward things like calls to methods
> >> in final classes, or calls to methods on objects allocated with 'new'
> >> in the current function.  (The latter could be done AOT, at least if
> >> you defined a way to do the appropriate runtime link; I've considered
> >> it for gcj.)
>
> Archie> I'm not that familiar with how your stuff works, but it sounds like
> Archie> you would have to do these optimizations before converting to LLVM
> Archie> format, right?
>
> Nope, I do all the optimizations after converting to LLVM, and in
> particular after the "promote memory to registers" pass has run (this
> fits into an implementation detail of my jit...).  It is just much
> simpler to do these kinds of things on the SSA representation.
>
> I thought more about what you are saying, and I think I understand the
> problem.  E.g., suppose we want to devirtualize not because a method
> is being called on the result of 'new' (since this is a particularly
> simple case) but because a method is being called on an object whose
> class happens to be 'final'.  In this case we need to know some
> properties of the java type.  (And, you can construct plenty of
> examples where java type information yields optimization
> opportunities.)

I think this example is even simpler than the method caled on the
result of new. When translating invokevitual on objects of final
classes just call the method directly and don't perform an indirect
function call though the vtable. Ditto for final methods.

--

Alkis