[llvm-dev] More function signatures for LLVMRunFunction?
Evan Miller via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 11 05:16:27 PDT 2016
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
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev