search for: getelementoffsetof

On Nov 5, 2007, at 8:27 PM, Nicolas Geoffray wrote: > 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

...ot;, "a" return What happens in Java is that types are created lazily. Which means you can compile getDoubleFromOne without knowing the layout of the class One. Therefore, if you compile getDoubleFromOne without the layout information, the compiler will generate the code: r2 = arg0 r1 = getElementOffsetOf("One", "a"); return r1(r2); getElementOffsetOf will trigger resolution of the class "One" and return some offset for "a". My goal here is to avoid having the call to getElementOffsetOf for the next executions of getDoubleFromOne. One solution is to recompil...

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

...b), execute a chunk of inline assembler to modify the caller (note: will probably need to modify inline asm syntax, as compilers tend to differ on this point...). something like this (figure out sort of how it works, and maybe mutate into something usable): int lookup_stub() { int i; i=getElementOffsetOf("One", "a"); asm { mov eax, i //return value mov edx, [ebp+4] //return addr mov byte [edx-5], 0xB8 //mov eax, imm32 mov [edx-4], eax //store return value in imm } return(i); }

BGB wrote: > ok, here is another option then: > the stub is set up to manually modify the code near the return address (may > be arch specific and require spiffy use of assembler). > > That's not another option. That's what I want to do. > now, how you would go about implementing this is up to you. > And I need to know if I can currently do that with LLVM.