[llvm-dev] More function signatures for LLVMRunFunction?

[Lang Hames via llvm-dev]

Hi Evan,

 ... is someone else already working on addressing the limitations of
> MCJIT's runFunction?


As far as I know nobody is actively working on MCJIT any more. I've been
working on the next generation of LLVM JIT APIs (ORC - see
include/llvm/ExecutionEngine/Orc) for a while now, but they don't have
functionality for running arbitrary functions yet.

Are there plans to support arbitrary function calls without a wrapper?


Not yet. At some point I had hoped to write some utility code to help build
the main()-compatible wrappers, but I haven't had time to work on it yet.

Is there interest in this functionality?


Definitely. I'd be happy to see something like this in ORC, and I think
there would be other people who would appreciate it too.

Right now the extended functionality just covers X86_64 with Windows and
> SysV calling conventions -- falling back to current behavior in all other
> cases. Do I need to cover other architectures / calling conventions with
> the patch, or is a little bit of platform-specific functionality OK?


I'd like to see a generic implementation that can handle all architectures
first, maybe with an specialized version for specific ABIs as an
optimization.

- Lang.


On Mon, Jul 11, 2016 at 5:16 AM, Evan Miller via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello,
>
> I am new to LLVM, and came across a snag when working through tutorials.
>
> With the MC JIT execution engine, LLVMRunFunction only works on
> "main()"-like functions -- other functions fail with the message
> "Full-featured argument passing not supported yet!". The workaround
> recommended by the tutorials is to create a main()-compatible wrapper
> function and to send in parameters via pointer.
>
> Are there plans to support arbitrary function calls without a wrapper?
>
> For what it's worth, I've been tinkering with a patch to the execution
> engine that will work with a wider array of functions, at least when the
> native host is X86. My idea is to support any function whose parameters all
> fit into registers by calling the function with a false (but
> ABI-compatible) function signature. E.g. on 64-bit X86 the parameter
> signature:
>
> (double, double, double, double,
> int64_t, int64_t, int64_t, int64_t)
>
> ...is ABI-compatible with any other function whose parameter list consists
> of up to 4 doubles and 4 integers / pointers. (Assuming 64-bit Windows or
> System V calling convention.) The nice part about this approach is that it
> doesn't require any assembly, just some C-style casts of function pointers,
> and covers a large class of function calls, including all the main()-like
> functions covered by the current implementation. But it won't cover
> function calls that require the stack for parameter passing (long doubles,
> large structs, varargs, etc).
>
> I am writing to this list ahead of formally submitting a patch because I
> have a few questions...
>
> * Is there interest in this functionality? I didn't see many references to
> LLVMRunFunction on the mailing list.
>
> * Relatedly, is someone else already working on addressing the limitations
> of MCJIT's runFunction?
>
> * Where should I put test code for this kind of change? I assume
> llvm/trunk/unittests, anywhere else?
>
> * Right now the extended functionality just covers X86_64 with Windows and
> SysV calling conventions -- falling back to current behavior in all other
> cases. Do I need to cover other architectures / calling conventions with
> the patch, or is a little bit of platform-specific functionality OK?
>
> I have some code that "works on my machine" but I'd like some assurance
> that I'm not duplicating existing efforts -- and also get a feel for what
> else I need to do before requesting a code review from the LLVM wizards. So
> any guidance on the above questions would be appreciated.
>
> Thank you!
>
> Evan
>
> --
> Evan Miller
> http://www.evanmiller.org/
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160714/8310fc64/attachment.html>