[LLVMdev] Dynamic (JIT) type resolution

[Nicolas Geoffray]

Hi everyone,

I would like to implement an equivalent mechanism of function callbacks
in the JIT, but for fields. Typically in Java, when you compile a
method, there may be some instructions (getfield, putfield) that depend
on a type which is not yet resolved.

I think the best way to do this in LLVM is to add an intrinsic. The 
intrinsic would be only valid if we jit, and would be lowered only in
the codegen part (don't know yet if it would be in the target dependent
or target independent part).

The callback method will resolve the type and patch the store/load
instruction so that the correct address is used (exactly like the JIT
function callback compiles a method and patch the call)

Now there is one issue to deal with here: how to represent the
intrinsic? It can either be 1) llvm.getfieldptr.{type} or 2) have two
kinds of intrinsics llvm.getfield.{type} and llvm.storefield.{type}.

I'd prefer using 1) since its closer to the LLVM instruction set
(GetElementPtrInst), however there may be some tricky issues on where
and how the  callback function must patch the code. For example, how are
move instructions (for spilling registers) inserted in LLVM? By choosing
1), can I face the issue of having a move instruction between the
getfieldptr call and the load/store? I probably can also face the
problem of code optimization, where the store/load would not be next to
the callback call.

Will I also have these issues with 2)? I don't know if LLVM does
optimization on DAG nodes. The dag nodes that I would like to generate
for a llvm.loadfield.{type} would be:

DAG.getCall(FieldCallback); // Or something similar, I don't know
exactly the syntax    ;-)   
DAG.getLoad();

When (if possible) can I be sure that these two instructions are next to
each other in the native code?

(Oh, and also, I would like codegen to not clobber caller-saved
registers when doing the call. Is that even possible? This is just an
optimization problem, so we can skip it for now).

Thanks,
Nicolas