Evan Miller via llvm-dev
2016-Jul-11 12:16 UTC
[llvm-dev] More function signatures for LLVMRunFunction?
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>
Lang Hames via llvm-dev
2016-Jul-15 01:35 UTC
[llvm-dev] More function signatures for LLVMRunFunction?
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>
Evan Miller via llvm-dev
2016-Jul-15 18:48 UTC
[llvm-dev] More function signatures for LLVMRunFunction?
Hi Lang, Thanks for the reply. Responses below. 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. >Thanks for the pointer to ORC -- it looks like the runFunction there is a copy-paste from MCJIT (minus the finalize() stuff). 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. >The basic approach I am using is to add a function to TargetMachine called runFunctionNatively: virtual GenericValue runFunctionNatively(Function *F, void *FPtr, ArrayRef<GenericValue> ArgValues); This houses most of the duplicated code currently in runFunction, and can then be called from either MCJIT or OrcMCJITReplacement. I then have an override for X86TargetMachine that uses the register trick. 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. >I agree a generic implementation would be ideal, but I don't know how to do a generic dynamic dispatch in C. Lacking that generic implementation, would you be interested in seeing what I have so far? Thanks! Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/48b0f140/attachment.html>