llvm dev - Nov 2007 - [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)
> 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.

> this should not be too difficult to implement I would think (albeit 
> admittedly I still don't know a whole lot about LLVM).
>
> hope this is of some use, in any case.
>
>
>   
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>     
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

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

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. Thus my initial
question :)
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>