<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Not to pile on the “LLVM tools are for debugging” bandwagon too hard here, but I’m pretty sure the clang driver can be used on source, IR, and disassembly. People shouldn’t be using llc and opt, instead they should just pass the IR files to clang.<div class=""><br class=""></div><div class="">Then clang can set the right target-specific defaults based on the clang flags.</div><div class=""><br class=""></div><div class="">That seems like a much more reasonable approach to the problem to me.<br class=""><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 17, 2015, at 12:26 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" class="">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Mar 17, 2015 at 11:13 AM, Dario Domizioli <span dir="ltr" class=""><<a href="mailto:dario.domizioli@gmail.com" target="_blank" class="">dario.domizioli@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Hello, LLVM.</div><div class=""><br class=""></div><div class="">We'd like to start a discussion about what would be the best way of</div><div class="">supporting target-specific defaults for options in the LLVM tools.</div><div class=""><br class=""></div><div class="">Problem description</div><div class="">-------------------</div><div class=""><br class=""></div><div class="">LLVM strives to be a generic compiler and it has a lot of code generation</div><div class="">options which are (rightly) not linked to the target triple.</div><div class="">However, some target triples do impose hard requirements for such options. For</div><div class="">example, PS4 requires the relocation model to be PIC. Cross-compilers for</div><div class="">specific target systems are likely to have similar restrictions.</div><div class=""><br class=""></div><div class="">One very effective way to ensure that users of Clang/LLVM don't misuse the</div><div class="">tools by passing the wrong options is to set the default values for those</div><div class="">options in the cross-compiler once the target triple is known. This has the</div><div class="">following rationale:</div><div class=""><br class=""></div><div class="">- Correctness: the user must be able to generate correct code for the target</div><div class=""> in the default workflow (with or without optimizations).</div><div class="">- Performance: the user should be able to generate good code for the target</div><div class=""> in the default workflow with optimizations enabled.</div><div class="">- Usability: although the default workflow could potentially be defined as</div><div class=""> "sorry, but you must pass options X, Y and Z to the tools", obviously it would</div><div class=""> be easier if it did not require such esoteric options.</div><div class=""><br class=""></div><div class="">And of course, from a company's point of view:</div><div class=""><br class=""></div><div class="">- Commercial reasons: if a tool is released commercially, the user expects such</div><div class=""> commercial product to work "out of the box" for the target system.</div><div class=""><br class=""></div><div class="">This is very easy to do in Clang, as the driver does the job of "dispatching"</div><div class="">the correct command line options to subsequent invocations of tools. Because of</div><div class="">the driver being the "middle man", it can parse the options, understand what the</div><div class="">target triple is, and invoke other tools accordingly (i.e. actively adding an</div><div class="">option, or erroring out upon encountering an invalid set of options).</div><div class=""><br class=""></div><div class="">A vendor can set the default target triple for Clang even at build time, and</div><div class="">this approach seems to not cause any trouble in the Clang tests (which don't get</div><div class="">as far as checking the output assembly). So for Clang the problem is solved to a</div><div class="">certain degree.</div><div class=""><br class=""></div><div class="">However, issues start to pop up when we consider all the other tools (opt, llc,</div><div class="">and so on) and the complications of having for example a "cross-llc". Usage of</div><div class="">such tools is becoming increasingly likely thanks to the existence of other</div><div class="">tools and frontends which can generate LLVM IR. Some crazy people might even try</div><div class="">to write IR instead of C++! :-)</div><div class=""><br class=""></div><div class="">First of all, overriding the defaults based on the triple is harder in LLVM</div><div class="">tools, because of how the cl::opt options work. If you consider llc, it</div><div class="">determines the triple in this sequence:</div><div class=""><br class=""></div><div class="">- Parse the IR and extract the triple if present.</div><div class="">- If there's a triple on the command line, override the IR triple.</div><div class="">- If no triple was found by either method, use the default triple.</div><div class=""><br class=""></div><div class="">This process is performed in the compileModule() function, which happens way</div><div class="">after the cl::init initializers for the cl::opt option defaults, and shortly</div><div class="">after the cl::ParseCommandLineOptions() call. If the value of some option needs</div><div class="">to be changed _after_ the triple has been determined, additional work has to be</div><div class="">performed to tweak the cl::opt options on the fly, but only if they had not</div><div class="">already been set on the command line (which would mean the user explicitly</div><div class="">wanted a non-default value). It would be quite ugly, although doable.</div><div class=""><br class=""></div><div class="">The real problem, however, is that tools are used not only by the end user, but</div><div class="">also extensively by the LLVM tests that check the output assembly.</div></div></blockquote><div class=""><br class=""></div><div class="">You have this completely backwards, and then some. The use case for these tools for testing is not "also". That is the only current use case that they are developed for. I'm not sure where you got the impression that they are meant to be used by end users, but that is just completely, flat-out incorrect.</div><div class=""><br class=""></div><div class="">-- Sean Silva</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Currently, there is a non-trivial number of LLVM tests that do not set the full</div><div class="">triple, but only parts of it, and then rely on specific default code generation</div><div class="">options. In the past, some defaults have been locked down as opposed to being</div><div class="">auto-detected (for example, -mcpu=generic) specifically for the purpose of</div><div class="">making tests stable and correct for cross-compilers.</div><div class=""><br class=""></div><div class="">Changing the code to override the defaults for opt, llc, and so on based on the</div><div class="">target triple can make some tests fail, because it would reinstate the same</div><div class="">problems we had before locking down such defaults. Of course, such a change</div><div class="">could be kept private and out of the open-source tree, and the tests could be</div><div class="">modified accordingly. However, it is clear that it could become a large burden</div><div class="">to support these private changes when new tests are constantly added to the</div><div class="">codebase.</div><div class=""><br class=""></div><div class="">We would like to start a discussion with the community about how best to support</div><div class="">the use case of "target-specific defaults for LLVM tools", especially in the</div><div class="">case of cross-compiling tools. Maybe somebody else is running into our same</div><div class="">use-case.</div><div class="">And this could even prove to be tied to the cl::opt reworking that was going on</div><div class="">a while ago, so new requirements / limitations / ideas might emerge.</div><div class=""><br class=""></div><div class="">We have identified a few approaches that could serve as the starting point of a</div><div class="">discussion. I will briefly outline them below. We don't want to push for any of</div><div class="">them, we just want to discuss them. There could even be more effective ways of</div><div class="">solving the problem, which is why we are interested in having this discussion</div><div class="">here.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">A - Fixed option defaults, irrelevant default triple logic</div><div class="">----------------------------------------------------------</div><div class=""><br class=""></div><div class="">I believe this is the current situation, possibly caused by how cl::opt works.</div><div class="">This alternative assumes that:</div><div class=""><br class=""></div><div class="">- There is no functionality in the open-source tree to change the defaults based</div><div class=""> on the target triple.</div><div class="">- Vendors may or may not change the default triple in their cross-compilers.</div><div class=""><br class=""></div><div class="">If a vendor wants to both change a tool to have a specific default triple, and</div><div class="">cause option defaults to depend on the triple, it is the vendor's responsibility</div><div class="">to adapt failing tests, and changes will have to be kept private. If a vendor</div><div class="">tried to push them onto the community ("yes, this -mcpu=generic in the test is</div><div class="">totally unnecessary, but can we have it in tree?"), such a change would never</div><div class="">pass a review.</div><div class=""><br class=""></div><div class="">If this approach is chosen, then vendors will have to maintain private changes,</div><div class="">but the state of the LLVM tests in the open-source tree will be consistent and</div><div class="">there will be no target-specific code to override option defaults.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">B - Triple-based option defaults, variable default triple logic</div><div class="">---------------------------------------------------------------</div><div class=""><br class=""></div><div class="">This alternative is at the other end of the spectrum and it assumes that:</div><div class=""><br class=""></div><div class="">- There is some functionality (a new API in llvm::cl?) in the open-source tree</div><div class=""> to override the defaults based on the target triple.</div><div class="">- The default target triple can be freely changed in cross-compilers, with</div><div class=""> impunity.</div><div class=""><br class=""></div><div class="">As described above, this would cause problems to some existing tests. It could</div><div class="">be argued though that, if a test is unstable with respect to code generation</div><div class="">options, then it should specify all options that it actually requires in order</div><div class="">to run properly.</div><div class="">This would mean that tests must specify a target triple in the RUN lines or in</div><div class="">the IR, otherwise they cannot assume that the code will be generated as</div><div class="">expected.</div><div class=""><br class=""></div><div class="">This puts a burden on the test implementors, but could it be argued that this is</div><div class="">technically correct? Shouldn't tests be robust? On the other hand, if tests had</div><div class="">to specify a target triple, wouldn't this reduce coverage (as they'd be testing</div><div class="">a single target as opposed to many)?</div><div class=""><br class=""></div><div class="">If this approach was chosen, then a good number of LLVM tests in the open-source</div><div class="">tree would need to be adapted, but vendors could be free to implement their own</div><div class="">defaults and set the default triple without significant consequences.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">C - Triple-based option defaults, fixed default triple logic</div><div class="">------------------------------------------------------------</div><div class=""><br class=""></div><div class="">This alternative assumes that:</div><div class=""><br class=""></div><div class="">- There is some functionality (a new API in llvm::cl?) in the open-source tree</div><div class=""> to override the defaults based on the target triple.</div><div class="">- Vendors are NOT free to change the logic determining the default triple.</div><div class="">- The default triple is inferred by some fixed logic, which is test-friendly.</div><div class=""><br class=""></div><div class="">There is code in the Clang driver that parses the program name to identify a</div><div class="">prefix that is used to determine the target triple. For example, I seem to</div><div class="">understand that "x86_64-scei-ps4-clang" would indicate a Clang which has a PS4</div><div class="">target triple by default.</div><div class="">Opt, llc, and similar tools do not support anything of the sort, so at the</div><div class="">moment the default target triple cannot be selected with the same approach.</div><div class=""><br class=""></div><div class="">Anyway, consider the case where option defaults are set based on the target</div><div class="">triple, but the default triple can be inferred from the name prefix, just as</div><div class="">Clang does; if no such prefix is found, the defaulting falls back to what we do</div><div class="">currently. This allows tests with RUN lines running "llc" to just use the triple</div><div class="">that we currently use, and therefore all existing open-source tests will</div><div class="">continue to work.</div><div class=""><br class=""></div><div class="">At the same time, a vendor could release a tool with a name prefix and reap the</div><div class="">benefits of having the desired defaults; and to make it convenient for the user,</div><div class="">a symlink (or something more complex on Windows) could easily be used.</div><div class=""><br class=""></div><div class="">If this approach was chosen, vendor-specific tests which expect the vendor</div><div class="">defaults would have to somehow rename the tool on the fly before running it; or</div><div class="">maybe they could change the build process to produce both an "llc" and a</div><div class="">"<triple>-llc" executables. Also vendors would need to release the renamed</div><div class="">tools, but this often happens anyway with cross-compilers. This pushes some</div><div class="">burden on the vendor, but it is much less than maintaining a lot of private</div><div class="">changes to the open-source code and tests.</div><div class=""><br class=""></div><div class="">What does the community think?</div><div class="">Discuss. :-)</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""> Dario Domizioli</div><div class=""> SN Systems - Sony Computer Entertainment Group</div><div class=""><br class=""></div><div class=""><br class=""></div></div>
<br class="">_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class="">
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></div></body></html>