<div dir="ltr">Hello,<div><br></div><div>I am new to LLVM, and came across a snag when working through tutorials.</div><div><br></div><div>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. </div><div><br></div><div>Are there plans to support arbitrary function calls without a wrapper?</div><div><br></div><div>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:</div><div><br></div><div>(double, double, double, double,</div><div>int64_t, int64_t, int64_t, int64_t)</div><div><br></div><div>...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).</div><div><br></div><div>I am writing to this list ahead of formally submitting a patch because I have a few questions...</div><div><br></div><div>* Is there interest in this functionality? I didn't see many references to LLVMRunFunction on the mailing list.</div><div><br></div><div>* Relatedly, is someone else already working on addressing the limitations of MCJIT's runFunction?</div><div><br></div><div>* Where should I put test code for this kind of change? I assume llvm/trunk/unittests, anywhere else?</div><div><br></div><div>* 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?</div><div><br></div><div>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.</div><div><br></div><div>Thank you!</div><div><br></div><div>Evan</div><div><br></div><div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Evan Miller<br><a href="http://www.evanmiller.org/" target="_blank">http://www.evanmiller.org/</a></div>
</div></div>