[LLVMdev] Re: Newbie questions
archie at dellroad.org
Wed Apr 26 14:42:11 PDT 2006
Tom Tromey wrote:
> 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.
Duh, you're right.. forget I mentioned static methods, static fields
are the only issue.
> 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.
That makes sense... though this is a more general optimization
that would handle excessive "active use" checks for static fields
as a side-effect.
My reason for bringing up the active use optimization is not
because I think it's so important, but just because it's an
example of something that - given a certain approach - is an
optimization that requires front-end knowledge of some kind.
I.e. it's a thought experiment.
> 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.
Those sound like good ideas.. multiple pass managers makes a lot
of sense.. e.g. the later ones can incorporate profiling information
gathered by the code generated by earlier ones, etc.
> 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 agree many juicy optimizations are probably already handled by LLVM.
For the ones that require a JVM-specific optimization pass, some
may have to wait until there is a way to pass JVM-specific information
to the JVM-specific optimization pass, or the LLVM language is
generalized sufficiently to express that information, or... ??
The "??" is an intereting theoretical question.. it doesn't
have to be solved today, but it probably has to be solved
eventually if LLVM is going to be a first-class JVM platform.
Archie Cobbs * CTO, Awarix * http://www.awarix.com
More information about the llvm-dev