[LLVMdev] appropriate for run-time compilation of DSL?

[edA-qa mort-ora-y]

On 04/11/2011 06:24 PM, Reid Kleckner wrote:
> That should work perfectly fine.  The LLVM JIT has support for
> declaring and calling out to native functions in the application
> through libffi.

How about support for a custom memory model? I know this sounds odd, but
basically the variables need to map to a specific block of memory: the
global heap. The enclosing program uses memcpy to push/pull values
in/out of that memory.

Would this be easy to do? Keep in mind I already generate byte-code, so
if needed I could simply emit offsets into the IR for all the places I
think it should be using.

> with a bit of the C++ ABI for any platforms you use.  For example, at
> the LLVM IR level calls will use names mangled according to the ABI

I can use C-Wrappers if it is easier.

> There isn't great support for this in the LLVM JIT, but IIRC some
> clients have managed this by subclassing the JITMemoryManager to copy
> the code when the function has finished being emitted.  I don't know
> if it's possible to ensure that the code will be position independent.

I'll start my investigation here then, as this is actually quite
critical to us -- we can't afford the final JIT/compilation overhead on
our target machines. Note that I do presume that LLVM is extremely fast,
but our requirements sit at the microsecond level, and we will have
thousands of these things to compile in a day.

Thank you for your assistance.

-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110412/83b0b1f2/attachment.sig>