<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Chris,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Thanks for clarifying that. That makes sense.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">So I apologize. It was not an error I got on the AddLazyIRModule. The issue is actually after I call AddLazyIRModule(). Performing a lookup on that global variable causes a hang. I've stepped through the debugger, and it seems to hang inside Core.cpp, ExecutionSession::lookup(). </blockquote><div><br></div><div>Are you (a) trying to JIT concurrently and (b) loading all modules on the same ThreadSafeContext? Notionally you should be able to do both, but in my experience bugs in this area are the most frequent source of deadlocks in lookup.</div><div><br></div><div>Are you able to get a backtrace for each thread in the debugger while the lookup is deadlocked? If you're using LLDB you can use "thread list" to list the threads, "thread select N" to switch to each, and "bt" to get the backtrace. I am not sure what the equivalent commands in GDB are. Either way, the lookup thread is the least interesting one: I expect to see some other thread waiting on a context lock, and the thing we *really* want to know is who owns the lock and how did they end up blocking while holding it.</div><div><br></div><div>Are you able to share any of your code / test cases?</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div><div>Prior to r367686, ORCv2 took out a lock on the context when a module was emitted and did not relinquish it until that module had been fully emitted. The problem with that is that if the module being emitted has dependencies on other modules living on the same </div><div></div><div><br></div><div>On Tue, Aug 13, 2019 at 2:09 PM chris boese <<a href="mailto:chris107565@gmail.com">chris107565@gmail.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Lang,<div><br></div><div>Thanks for clarifying that. That makes sense.</div><div><br></div><div>So I apologize. It was not an error I got on the AddLazyIRModule. The issue is actually after I call AddLazyIRModule(). Performing a lookup on that global variable causes a hang. I've stepped through the debugger, and it seems to hang inside Core.cpp, ExecutionSession::lookup(). </div><div><br></div><div>Thanks,</div><div>Chris</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2019 at 2:33 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi Chris,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Thanks so much for the quick help. I was able to find them after changing the linkage. Does this new orc JIT follow different standards than the MCJitReplacement? We used to set a lot of our functions/globals to internal linkage before doing a lookup.</blockquote><div><br></div><div>They are different: ORCv2 follows the static linker's lookup rules, whereas MCJITReplacement mimicked MCJIT's rules which were never clearly spelled out, but in practice allowed you to search for internal symbols.</div><div><br></div><div>The advantage of the new scheme is that if you are compiling/running something on the command line. E.g.:</div><div><br></div><div>$ llc -filetype=obj -o extra.o extra.ll</div><div>$ llc -filetype=obj -o prog.o prog.ll</div><div>$ clang -o prog prog.o extra.o</div><div>$ ./prog</div><div><br></div><div>Then you can add the same modules to the JIT and expect the resulting JIT'd code to behave the same as the statically compiled code. E.g. (omitting some error handling for clarity):</div><div><br></div><div>J->addIRModule(loadModule("extra.ll"));</div><div>J->addIRModule(loadModule("main.ll"));</div><div>auto Main = (int(*)())J->lookup("main").getAddress();</div><div>Main();</div><div> <br></div><div>If you are generating code specifically for the JIT it is often easiest to just use external linkage and default visibility for all symbols. However, for people who want to hook up an existing front-end, or to use more advanced features in their JIT (duplicate symbol names with internal linkage, symbols with weak linkage, hidden visibility, etc.) this scheme has the nice property that "What does linker-feature X do in the JIT?" is more-or-less equivalent to "What does linker-feature X do in a regular build". The answer to the latter question is generally more widely known, and is much easier to test from the command line.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">When adding a new module with a single global variable in it, I get an error during the addLazyIRModule.</blockquote><div><br></div><div>Are you hitting an assertion, or is addLazyIRModule returning a non-success value? If the latter, what is the error message?</div><div>(You can find this by calling 'logAllUnhandledErrors(std::move(Err), errs(), "")', or, in tool code, using the ExitOnError utility: <a href="http://llvm.org/docs/ProgrammersManual.html#using-exitonerror-to-simplify-tool-code" target="_blank">http://llvm.org/docs/ProgrammersManual.html#using-exitonerror-to-simplify-tool-code</a>).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Right now we are treating the module as one big single module, and when we go to lookup a symbol, I believe we are jitting the entire thing. Once we make the switch to LLLazyJIT, we want to start splitting up our modules.</blockquote><div><br></div><div>If you are using MCJITReplacement you are definitely JITing the whole module up-front, and in that case lazy compilation may help reduce your compile time. I'd love to hear how it works for you!</div><div><br></div><div>Cheers,</div><div>Lang.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2019 at 10:26 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><a class="gmail_plusreply" id="gmail-m_3624009229622175665gmail-m_7363326224696822258gmail-m_-6815707226106742783plusReplyChip-0" href="mailto:lhames@gmail.com" target="_blank">+Lang Hames</a>, Admiral of the Orcish Fleet (Lang's the primary developer/creator of the ORC JIT & might have some answers to your question)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 8, 2019 at 4:15 PM chris boese via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>We are trying to switch to the new orc v2 lljit engine at my work with hopes of parallel jitting. We are switching from the ExecutionEngine w/ OrcMCJitReplacement. We are having a hard time with global variables. We have found a way to create/emit new globals during jitting by using the old ExecutionEngine::getOrEmitGlobalVariable. Is there an easier way to do this with the new jit engine? We were hoping to create a new ThreadSafeModule, add a GlobalVariable, and then add the module to the JIT engine through addLazyIRModule(), but this doesn't seem to work. </div><div><br></div><div>2nd question; Is the lookup function supposed to work with global variables by name? Looking through the CompileOnDemandLayer it seems to change the names of globals to "__orc_lcl.<name><id>". Does this affect the lookup methods? I noticed that all of the globals we are looking for are tagged with Internal linkage and end up getting emitted through extractSubModule().</div><div><br></div><div>Any help is appreciated.</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div></div></div></div>