[LLVMdev] Dynamic (JIT) type resolution

[BGB]

----- Original Message ----- 
From: "Nicolas Geoffray" <nicolas.geoffray at lip6.fr>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Wednesday, November 07, 2007 10:03 AM
Subject: Re: [LLVMdev] Dynamic (JIT) type resolution


> BGB wrote:
>> maybe a tradeoff is possible:
>> the function to get the offset is replaced by a function pointer and a 
>> stub
>> (avoiding many of the general problems involved with using
>> self-modifying-code).
>>
>
> For me there are no problems of self-modifying code (the LLVM jit
> already does it)
>

there are, 'further' problems, than simply having a JIT generate the code...


>> the fist time it is called, the function pointer points to 'stub A', 
>> which
>> calls the function to lookup the slot offset,
>> this function then stores the value in a variable, and updates the 
>> function
>> pointer to point to 'stub B'.
>>
>> 'stub B', simply returns the value stored in the variable.
>>
>>
>>
>
> That's again what I want to avoid. This is my current implementation,
> and I _really_ would like to avoid unnecessary calls once the type is
> resolved.
>

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).

an example is this (assuming x86):
for the stub, as opposed to executing a 'ret', you have something like this 
in its place:
pop edx
mov byte [edx-5], 0xB8    ;mov eax, imm32
mov dword [edx-4], eax    ;store return value in imm
jmp edx

this will replace the 'call' instruction generating the call with a mov, 
thus further runs will not invoke a call (note, be very sure this stub is 
only ever called with a 'call' instruction).

(in LLVM, though I am not certain as I don't know much of the internals, 
this could require either tweaking the codegen, or hand-crafted stub 
generation).


now, how you would go about implementing this is up to you.