llvm dev - Oct 2006 - [LLVMdev] lli in interpreter mode and external native libraries

Chris Lattner wrote:
> 3. Best: Find a "foreign function interface" library, and use
that to
>     interface to native code.
>   
This is the only option that's really usable, unfortunately, because I 
have no control over what code some potential user might want to model 
check.

I was wondering whether there might be anything in the JIT support that 
could be reused for this purpose?

I can't really move to using the JIT entirely because I want to replace 
the memory model with something that supports backtracking -- this is 
doable (fairly) straightforwardly with the interpreter, but it would 
require some very complicated transformations to the code in order to do 
this within the JIT environment, and it would be quite tricky to avoid 
subtly breaking the semantics. That kind of approach is possible, 
probably, but not really something I want to attack right now.

Thanks,
Sarah

On Thu, 26 Oct 2006, Sarah Thompson wrote:
> Chris Lattner wrote:
>> 3. Best: Find a "foreign function interface" library, and use
that to
>>     interface to native code.
>>
> This is the only option that's really usable, unfortunately, because I
> have no control over what code some potential user might want to model
> check.
Ok.
> I was wondering whether there might be anything in the JIT support that
> could be reused for this purpose?
The JIT has a superset of this functionality.  However, if there is JIT 
support for the host that you are interested in, you shouldn't have to use 
the interpreter at all.
> I can't really move to using the JIT entirely because I want to replace
> the memory model with something that supports backtracking -- this is
> doable (fairly) straightforwardly with the interpreter, but it would
> require some very complicated transformations to the code in order to do
> this within the JIT environment, and it would be quite tricky to avoid
> subtly breaking the semantics. That kind of approach is possible,
> probably, but not really something I want to attack right now.
Ok.  The easiest (in some senses) approach would be to do what you say 
above.  However, you could probably arrange for a mixed approach to work. 
in particular, you could have the JIT dynamically compile the FFI code you 
need by dynamically generating the "unpack from GenericValue" code for
each callee you are interested in.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Chris Lattner wrote:
>
> The JIT has a superset of this functionality.  However, if there is JIT 
> support for the host that you are interested in, you shouldn't have to
use
> the interpreter at all.
>
>   
For interpreting, yes, but model checking is weirder so it's greatly 
beneficial to be able to heavily hack an interpreter.
>> I can't really move to using the JIT entirely because I want to
replace
>> the memory model with something that supports backtracking -- this is
>> doable (fairly) straightforwardly with the interpreter, but it would
>> require some very complicated transformations to the code in order to
do
>> this within the JIT environment, and it would be quite tricky to avoid
>> subtly breaking the semantics. That kind of approach is possible,
>> probably, but not really something I want to attack right now.
>>     
>
> Ok.  The easiest (in some senses) approach would be to do what you say 
> above.  However, you could probably arrange for a mixed approach to work. 
> in particular, you could have the JIT dynamically compile the FFI code you 
> need by dynamically generating the "unpack from GenericValue"
code for
> each callee you are interested in.
>   
That's what I'm currently trying -- it looks reasonably straightforward.

Sarah