[LLVMdev] Re: Newbie questions

[Tom Tromey]

>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes:

Archie> Which bytecode will you recompile? In particular I'm thinking
Archie> about active use checks: as you know the checks for class A have to
Archie> be implemented in every other class B, C, D, ... that references a
Archie> static field or method of A. Presumably you won't recompile every
Archie> class that references A after A is initialized...

In libgcj, static methods initialize their declaring class.  So it is
only static fields we have to worry about.  This may not be the best
choice but for the time being I'm just trying to fit my jit into the
existing world.

Optimizations are still a ways off for me, but my thinking was, we'd
have a flag per method indicating whether it may make sense to
recompile it.  This flag would be set if we see an uninitialized
class, unresolved constant pool entry, etc.  If the flag is set and
the method is called frequently enough, then we try to recompile.

I'm also considering having multiple pass managers, and promoting
methods from one manager to the next, depending on how heavily the
method is used.

Maybe this is all naive.  Feel free to let me know :-)

My plan in general is just to experiment with different things and see
what works.

Archie> I.e., my question is the more general one:
Archie> how do optimizations that are specific to the front-end language get
Archie> done? How does the front-end "secret knowledge" get passed through
Archie> somehow so it can be used for optimization purposes?

Archie> With no annotation support, it doesn't seem like you can. This is
Archie> the problem. I'm not saying annotations are good, just that they
Archie> represent one (sub-optimal) solution to the problem. Without them,
Archie> we have zero solutions to the problem.

I think the simpler optimizations (class initialization, constant pool
resolution, division by zero check elimination, null pointer check
elimination, array bounds check elimination) can all be done pretty
simply without needing special LLVM support, either by generating
different LLVM code up front (and arranging to recompile on demand),
or by having a simple JVM-specific LLVM optimization pass.

I haven't thought much about more complicated optimizations like
escape analysis or devirtualization or whatnot.

What kinds of things are you thinking of?

Tom