<div dir="ltr">Hi Evan,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px"> ... is someone else already working on addressing the limitations of MCJIT's runFunction?</span></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">Are there plans to support arbitrary function calls without a wrapper?</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">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.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">Is there interest in this functionality?</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">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.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">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?</span></blockquote><div><span style="font-size:13px"><br></span></div><div>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.</div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">- Lang.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 11, 2016 at 5:16 AM, Evan Miller via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><span class="HOEnZb"><font color="#888888"><div><br></div><div>Evan</div><div><br></div><div>-- <br><div data-smartmail="gmail_signature">Evan Miller<br><a href="http://www.evanmiller.org/" target="_blank">http://www.evanmiller.org/</a></div>
</div></font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>