<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 18, 2015 at 12:04 AM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><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"><div dir="ltr"><br><br><div class="gmail_quote"><span class="">On Tue, Mar 17, 2015 at 11:45 AM Akira Hatanaka <<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>> wrote:<br><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 16, 2015 at 2:14 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><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"><div dir="ltr"><br><br><div class="gmail_quote"><span>On Mon, Mar 16, 2015 at 8:27 AM Akira Hatanaka <<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>> wrote:<br><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 13, 2015 at 4:09 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><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">No, you probably haven't. I was seeing it as clang doing to lto link of the module together and then codegen based on that (which means it would have the options), but...<br>
<br>
That said, I think the general problem is more specific. I.e. how do you specify -msse3 as part of the default code generation flags when you do lto?<br>
<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>In LTOCodeGenerator.cpp, SubtargetFeatures::getDefaultSubtargetFeatures is called to get the default subtarget features and the string is passed to TargetCreateTargetMachine.</div><div><br></div><div>Is that what you are asking about?</div></div></div></div></blockquote><div><br></div></span><div>Yes, but that code doesn't work in the abstract. It only works on darwin because it has hard coded values. The features there are only based on the triple so saying that you want to pass in a default of -msse3 to your code generator doesn't work unless you a) hard code a cpu into LTOCodeGenerator.cpp or, b) hard code it into the triple (x86_64h anyone?).</div><span><font color="#888888"><div><br></div></font></span></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The commit message of r165809 explicitly states the code in LTOCodeGenerator.cpp was committed as a temporary hack, so it should be replaced with something else or removed to work on non-darwin platforms.</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>I'm not too worried about this from the lto perspective. The rest of the code generation where the default features are different from the module ones will work with the clang patch that we talked about that encodes subtarget features on the functions. I apologize that I used -msse3 as my example, I think it sent the discussion down a poor path and not what I intended.</div><span class=""><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>I see that getTargetCPU and getTargetFeatureString are called only in AsmPrinter or its subclasses to create a default subtarget. I think in most cases the default cpu can be determined by scanning all the target-cpu that are stored as function attributes in the IR, but the algorithm to determine it would be highly target specific.<br></div><div><br></div></div></div></div></blockquote><div><br></div></span><div>This wouldn't be such a good idea.</div><span class=""><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>I'm not sure if it's correct to use a single "default" cpu or feature string to assemble a module-level inline-asm. Suppose we compile two files that have file-level inline assembly statements using different command line options (different target cpu and features), link the IRs, and compile the combined IR. In that case, shouldn't we be constructing two different subtargets based on the command line options that were used to compile each file instead of constructing a single "default" subtarget as we do now? Or should we just drop support for file scope inline asm when we do function multiversioning or LTO?</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>Function multiversioning isn't relevant here, it involves per function code generation it's true, but shouldn't affect anything at the module level. I was more worried about:</div><div><br></div><div>clang foo.c -emit-llvm -o foo.bc</div><div>clang bar.c -emit-llvm -o bar.bc</div><div>clang -msse3 foo.bc bar.bc -flto -o foo.x</div><div><br></div><div>where the -msse3 would override the default triple on the architecture. It's probably not too big of a worry from the perspective of code generation, but rather seemed like something someone might do for lto (more on this in a bit).</div><div><br></div><div>Largely I hate module level inline assembly, that said we should probably allow people to do weird things in LTO that they're allowed to do in normal code generation.</div><span class=""><div> </div></span></div></div></blockquote><div><br></div><div>We might have to change the representation of module-level inline-asm in the IR, if we are going to allow users to compile module-level inline-asm statements in two different files using different command line options. Currently, module-level inline-asm is just a concatenated string, so there is no way to say which part of the inline-asm string is compiled with which options.</div><div> </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"><div dir="ltr"><div class="gmail_quote"><span class=""><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>I'm talking about a case like this, where two files foo1.c and foo2.c are compiled with LTO.</div><div><br></div><div>$ clang -mips16 foo1.c -o foo1.bc -flto -c -target mipsel</div><div><div>$ clang foo2.c -o foo2.bc -flto -c -target mipsel</div></div><div><div>$ clang foo1.bc foo2.bc -o foo -flto -target mipsel</div><div><br></div></div></div></div></div></blockquote><div><br></div></span><div>Right, not too awful concerned here.</div><div><br></div><div>Here though (and referencing Ahmed's other email), we're talking about passes being enabled via subtarget options in the default pipeline but can be turned off by a single -mno-global-merge in the pipeline somewhere? One of those reasons why I thought having such global options enabled by command line at lto time to be a better idea. The command line option side would still be handled by clang, it'd just be the interface via the linker that would need to be expanded to pass down code gen options. Also it avoids having every module pass that we want to turn on and off at lto time needing to be handled on a per module basis as well as being able to use the basic command line parsing to handle things like LTO -O1 or -Oz or -Os or -O3 -fno-vectorize ...</div><div><br></div><div>Thoughts?</div><span class=""><font color="#888888"><div><br></div></font></span></div></div></blockquote><div><br></div><div>Does it mean that global-level options such as global-merge would be passed at link time? Function level options such as -msse3 would be a compile time option, is that correct?</div><div><br></div><div>$ clang foo.c -emit-llvm -o foo.bc -msse3</div><div>$ clang bar.c -emit-llvm -o bar.bc -msse3</div><div>$ clang -mno-global-merge foo.bc bar.bc -flto -o foo.x</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"><div dir="ltr"><div class="gmail_quote"><span class=""><font color="#888888"><div></div><div>-eric</div></font></span><span class=""><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div></div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><div dir="ltr"><div class="gmail_quote"><span><font color="#888888"><div></div><div>-eric</div></font></span><span><div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </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">
The C++ interface has addAttr (which is painful in that it requires, as you say, every linker to understand llvm's command line interface), but this is also pretty painful:<br>
<br>
const void *compile(size_t *length,<br>
bool disableOpt,<br>
bool disableInline,<br>
bool disableGVNLoadPRE,<br>
bool disableVectorization,<br>
std::string &errMsg);<br>
<br>
because, you know, all optimizations, inlining, gvnloadpre, and vectorization are all anyone care about :)<br>
<br>
Realize this has dovetailed into "let's solve the general problem" but I am curious. The gold plugin's methods aren't much better.<br>
<br>
Or am I missing something?<br>
<div><div><br>
-eric<br>
<br>
<br>
<a href="http://reviews.llvm.org/D7968" target="_blank">http://reviews.llvm.org/D7968</a><br>
<br>
EMAIL PREFERENCES<br>
<a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</div></div></blockquote></div></div></div></blockquote></span></div></div>
</blockquote></div></div></div></blockquote></span></div></div>
</blockquote></div><br></div></div>