<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 18, 2015 at 7:49 AM, Dario Domizioli <span dir="ltr"><<a href="mailto:dario.domizioli@gmail.com" target="_blank">dario.domizioli@gmail.com</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">Sorry to be a bit controversial, but as a follow-up from this thread, should we then explicitly document that opt, llc and lli are debugging tools in the LLVM documentation?<div><br></div><div>The LLVM User Guide main page says that "<span style="color:rgb(0,0,0);font-family:'Lucida Grande','Lucida Sans Unicode',Geneva,Verdana,sans-serif;font-size:14px;line-height:21px">The documentation here is intended for users who have a need to work with the intermediate LLVM representation."</span></div><div>So yes, it is for advanced users, but this wording appears to include users having their own IR generators (they are technically "working with the intermediate representation").</div><div><br></div><div>The official man pages for llc, opt and lli certainly make them look like standalone and usable tools:</div><div><a href="http://llvm.org/docs/CommandGuide/llc.html" target="_blank">http://llvm.org/docs/CommandGuide/llc.html</a><br></div><div><a href="http://llvm.org/docs/CommandGuide/opt.html" target="_blank">http://llvm.org/docs/CommandGuide/opt.html</a><br></div><div><a href="http://llvm.org/docs/CommandGuide/lli.html" target="_blank">http://llvm.org/docs/CommandGuide/lli.html</a><br></div><div>I can't find anything explicit about them only being debugging/testing tools, nor anything explicitly discouraging their use in production.<br></div><div><br></div><div>Even the "Getting Started with the LLVM System" documentation uses llc in the example!</div><div><a href="http://llvm.org/docs/GettingStarted.html#an-example-using-the-llvm-tool-chain" target="_blank">http://llvm.org/docs/GettingStarted.html#an-example-using-the-llvm-tool-chain</a><br></div><div>If llc is just a debugging/testing tool, why does the documentation tell beginners (the obvious target of a "getting started" document) about its existence?!</div></div></blockquote><div><br></div><div>Being a "beginner" is a completely orthogonal. You can be a beginning LLVM developer, and you will need these tools for testing and developing. You can be an experienced LLVM developer, and you will need these tools for testing and developing.</div><div><br></div><div>As a first approximation, these tools are for people that are actually writing code that programmatically interacts with LLVM (either through a direct API call or by generating .ll or .bc that is meant to be consumed by those API's).</div><div><br></div><div>I'm not sure that there is consensus about this exact terminology, but in the context of LLVM, this is a rough categorization of different roles (a person can fall into multiple categories):</div><div>A. LLVM "developers" develop in the LLVM codebase</div><div>B. LLVM "users" programmatically interact with LLVM from their own code that is not in the LLVM codebase</div><div>C. LLVM "end users" use tools that happen to be built on LLVM. From their perspective, the tools could be built on another compiler technology (in the same way that clang is based on a different compiler technology than gcc), since there is nothing about LLVM per se that they directly care about.</div><div><br></div><div>(note that these are the terms used from the perspective of LLVM. B calls C "users"). As an analogy:</div><div><br></div><div>A. libpng developers</div><div>B. people that develop code using libpng (e.g. browser developers)</div><div>C. people that look at images in PNG format that were decoded by libpng (e.g. people that use browsers that decode their images with libpng)</div><div><br></div><div>LLVM is in a special position because since it is a compiler, group C are also programmers, so the distinction is less obvious. What people have been saying in this thread is that group C should not be exposed to llc, opt, llvm-mc, etc.</div><div><br></div><div>Within LLVM, there are very few tools that are targeted at "end users". The primary ones are clang and lld (also clang-format and some of the other clang tools).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>It could be argued that advanced users "should know better", but the documentation could be clearer too.<br></div><span class=""><div><br></div><div>Cheers,</div><div> Dario Domizioli</div><div> SN Systems - Sony Computer Entertainment Group</div><div><br></div><div><br></div><div><br></div></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 18 March 2015 at 00:17, Dario Domizioli <span dir="ltr"><<a href="mailto:dario.domizioli@gmail.com" target="_blank">dario.domizioli@gmail.com</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"><div><div><div><div>Thanks for all the replies!<br><br></div>Whoa, it looks like there's pretty much a massive consensus on "use clang and never use opt/llc in that kind of scenario".<br><br></div>I appreciate that opt and llc are mainly debugging/testing tools.<br>The problem is mainly that these programs "are there" in the open source build of LLVM. Users know that they're getting a product based on open source LLVM, so:<br>- If opt and llc were not shipped, then it would be reasonable for users to ask: "why can't we have them?"<br></div>- If they were shipped, then it would be reasonable for users to ask: "can we have them just work?"<br></div><div><div><div><div><div><br>Also, intuitively it feels that llc could be more lightweight / performing compared to clang (which
has to spawn a second process), although I admit that I don't have
performance numbers for this comparison (yet).<br><div><br><div>Anyway, now we definitely have an answer for the two questions above. :-)<br><br></div><span><div>Cheers,<br></div><div> Dario Domizioli<br></div><div> SN Systems - Sony Computer Entertainment Group<br></div><div><br></div><br><br></span></div></div></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 17 March 2015 at 20:27, David Jones <span dir="ltr"><<a href="mailto:djones@xtreme-eda.com" target="_blank">djones@xtreme-eda.com</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"><div><div><div><div><div><div>What is the preferred method for compiler (frontend) developers to optimize and generate target machine code from IR?<br><br></div>At one point I found a tutorial that recommended simply dumping the IR to a file and spawning llc to do the job.<br><br></div>Up until now I have "manually" created a TargetMachine, PassManager, etc. to generate my object code. The initial version of my code was cribbed from llc for LLVM 3.2, and has since been updated for 3.5.1.<br><br></div>However, with every new release of LLVM, the API to the backend optimization and code generation passes changes. The changes from 3.5.1 to 3.6 are quite significant. If I'm lucky, the impact of a change is that my C++ code refuses to compile, and I have to fix. If I'm unlucky, the impact may be that my code compiles and runs, but LLVM works suboptimally - perhaps some optimizations don't happen. (This can happen if a newer API expects me to do some step which was not required in earlier releases, and there is no assert to catch it.)<br><br></div>As an alternative, I am seriously considering "simply dumping the IR to a file and spawning llc" to perform my backend work. The API to create IR is much more stable than the API to do useful things with it. Furthermore, it's a lot easier to manually debug IR that has been dumped to a file. Finally, I can spawn multiple, independent, concurrent invocations of llc on a multi-core machine. I needn't worry about concurrency, as the standard Linux fork/waitpid type calls will suffice. Given that 90% of my runtime is spent inside LLVM, I get 90% of the benefit of a fully concurrent design with almost zero work.<br><br></div>But now it seems that this usage model is frowned upon.<br><br></div>What is the recommended usage model?<br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Mar 17, 2015 at 2:32 PM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Mar 17, 2015, at 11:13 AM, Dario Domizioli <<a href="mailto:dario.domizioli@gmail.com" target="_blank">dario.domizioli@gmail.com</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">What does the community think?</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Discuss. :-)</div></div></blockquote></div><br></span><div>Devil’s advocate: opt, llc, lli, etc. are development/debugging tools for LLVM developers, not for end users, and the project optimizes their functionality for that use case.</div><span><font color="#888888"><div><br></div><div>—Owen</div></font></span></div><br></div></div><span>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>