[llvm-dev] More function signatures for LLVMRunFunction?

[Evan Miller via llvm-dev]

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160711/7af5c2e5/attachment.html>