<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 16, 2017 at 11:17 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 16, 2017, at 11:02 AM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div><br class="m_7842279911301146231Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 16, 2017 at 10:22 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Jan 16, 2017, at 10:00 AM, Sean Silva via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_7842279911301146231m_-2478622514022924654m_7035514472385865050Apple-interchange-newline"><div><div dir="ltr">What is the end goal? If the goal is roughly "if a user passes -O0 when compiling a TU in LTO mode, their final binary should have functions that look like the result of -O0 noLTO compilation", then the frontend can just emit a normal -O0 object file I think. What is the advantage of passing bitcode all the way to the linker only to jump through hoops to prevent LTO code generation from modifying it?</div></div></blockquote><div><br></div></span><div>That’s a good point, that addresses the “I want LTO for optimization”, which seems contradictory to use `-flto -O0`, and could even advocate for forbidding (or warning).</div><div><br></div><div>However LTO has other uses than optimizations: for instance instrumentations that needs full program access.</div><div>One of them is CFI: <a href="http://clang.llvm.org/docs/ControlFlowIntegrity.html" target="_blank">http://clang.llvm.org/doc<wbr>s/ControlFlowIntegrity.html</a></div><div>If you want to debug and rebuild only part of the program, CFI still requires to use LTO, IIUC.</div></div></div></blockquote><div><br></div><div>That's a good point. I wonder if there are any commonalities of this problem and the "hosted"/"freestanding" issues recently? These all seem to tie into a common theme of "when I use LTO, various per-TU settings don't make it to the LTO code generator"; can we adopt a uniform solution for this class of problems, like always using function attributes or something? This probably won't be the last of such issues, and we should have a "standard solution" for them.</div></div></div></div></div></blockquote><div><br></div></span><div>Yes, the optnone thing is indeed part of the work to bring “everything” needed to setup TLI, CodeGen and so on into function attributes.</div><div>I was working on the TLI and "pulling strings" I ended-up starting with optnone.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Taking a step back, consider the "trend" as we try to persist more per-TU options to LTO: we will have more and more attributes (or whatever) telling the optimizer and code generator what to do in greater and greater detail.</div><div>In such a world, what is the role of the frontend setting up the pass pipeline, target info, etc. using calls into the LLVM libraries? If, for LTO, we have to serialize those things anyway, then should frontends prefer to simply add the annotations into the IR instead of making calls into the LLVM libraries to configure the code generation?</div></div></div></div></div></blockquote><div><br></div></span><div>Yes, as much as possible. This is inline with the work Eric has been doing about having subtargets selected/configured with function attributes. We’re also trying to get rid of global flags in SelectionDAG or other phases of the codegen in favor of function attributes or individual instruction flags for Fast-Math.</div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Things like -mllvm options suggest that we're never really going to persist "everything affecting codegen" into the IR on a per-TU basis during LTO (can't control -mllvm options per-function).</div></div></div></div></div></blockquote><div><br></div></span><div>I believe -mllvm options are supposed to be “developer options” only and are not “supported” or supposed to be exposed to the end user. For example I don’t believe the clang docs is referencing the -mllvm, right?</div></div></div></blockquote><div><br></div><div>Oh, derp. You're totally right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> So is our approach here basically to persist compilation options into the IR on an as-needed (i.e. ad-hoc) basis? E.g. we go out of our way to persist -O0 (using e.g. optnone) but don't do anything special for -O1. Also what is the interaction with --lto-O[0123]? (i.e. linker options controlling the optimization level used during LTO codegen)</div></div></div></div></div></blockquote><div><br></div></span><div>The discussion in the revision addressed this, but in particular the last comment of Chandler in the revision should answer this somehow: <a href="https://reviews.llvm.org/D28404" target="_blank">https://reviews.llvm.<wbr>org/D28404</a></div><div><br></div><div>"<span style="font-family:'Segoe UI','Segoe UI Web Regular','Segoe UI Symbol',Lato,'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px">Unlike the differences between -O[123], all of -O0, -Os, and -Oz have non-threshold semantic implications. So with this change, I think we will have *all* the -O flags covered, because I view '-O[123]' as a single semantic space with a threshold modifier that we *don't* need to communicate to LTO. We model that state as the absence of any attribute. And -O0, -Os, and-Oz have dedicated attributes.</span></div><p style="margin:0px 0px 12px;padding:0px;border:0px;font-family:'Segoe UI','Segoe UI Web Regular','Segoe UI Symbol',Lato,'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px">If we ever want to really push on -Og, that might indeed require an attribute to distinguish it."</p><div><br></div><div>I reproduced above only one sentence, but I encourage to read the full comment :)</div></div></div></blockquote><div><br></div><div>Very nice.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I'm just trying to understand the bigger picture here.</div></div></div></div></div></blockquote><div><br></div><div><br></div></span><div>It’s not always totally clear to me either :)</div><div>Some options are making sense “per TU” while others can make sense “per-function” as well! </div><div>This can be inherent to what the option describes, or because the user interface is not uniform:</div><div>- for some options, the interface is both the command line and the source code attributes like `optnone`, `noinline`.</div><div>- for other options only the command line is available, like `freestanding`, `nobuiltin` (not sure for this one?)</div><div>- and some options are only available in the source: disabling the sanitizer for example.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>It changes over time as well, at some point the subtargets options were a property of the TU, while it has been promoted to a per-function attribute.</div><div><br></div><div>Finally, this is also a very “clang-centric” vision of the user-interface, other client of LLVM can bring more into the mix.</div><div><br></div><div>I have the impression that function attributes when possible seems the more flexible for all the clients overall.</div></div></div></blockquote><div><br></div><div>That's my thinking too.</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 style="word-wrap:break-word"><div><div><br></div><div>— </div><span class="HOEnZb"><font color="#888888"><div>Mehdi</div></font></span><div><div class="h5"><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Personally, my mental model has always been that the flags that you pass to per-TU compilation are instructions for that compilation, and should not influence things like optimization level for LTO code generation (which will run at a different time in a different program). That's at least easy to document.</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 style="word-wrap:break-word"><div><div><br></div><div>— </div><span class="m_7842279911301146231m_-2478622514022924654HOEnZb"><font color="#888888"><div>Mehdi</div></font></span><div><div class="m_7842279911301146231m_-2478622514022924654h5"><div><br></div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div><div>-- Sean Silva</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 11, 2017 at 8:34 AM, Robinson, Paul 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">In D28404, Mehdi wanted to use the 'optnone' attribute as a way to record<br>
"I was compiled with -O0" in the IR, because it seems like a good idea to<br>
remember that fact in an LTO compilation and there is no way to remember<br>
that fact currently.  A couple of people felt it might be better to have<br>
this idea discussed on the dev list, where it might get better exposure,<br>
so I'm volunteering to get that discussion started.<br>
<br>
While 'optnone' does cause lots of optimizations to bypass a function,<br>
exactly matching -O0 was not the motivation and never a hard requirement.<br>
The implementation makes a distinct effort to get close to the behavior<br>
of -O0, but it's not an exact match and for the intended purpose (allowing<br>
a given function to be un-optimized to help debugging) it worked fine.<br>
<br>
Using 'optnone' to convey -O0 to LTO is something of a redefinition, or<br>
at least a re-purposing, of the attribute.  To get there from here, I<br>
think we would need a couple of things to happen, separately from the<br>
minor grunt work of adding 'optnone' to function IR at -O0.<br>
<br>
1) Update the LangRef definition of 'optnone' to reflect this intent.<br>
The current definition doesn't provide a motivation, and the description<br>
is (deliberately) a bit vague.  If we want 'optnone' to intentionally<br>
match -O0, that should be tightened up.<br>
<br>
2) Make a concerted effort to teach 'optnone' to targets.  Currently<br>
I know the X86 target is aware of it, but I'm not so sure about others.<br>
<br>
3) Take another look at what 'optnone' currently does *not* turn off,<br>
and see if there is something we can do about that.  In some cases this<br>
will not be practical, and we may just have to live with that.<br>
<br>
(Okay, we need 3 things to happen.)<br>
<br>
I won't say this is blocking Mehdi's work, but it would remove a<br>
point of contention and allow the review to proceed more smoothly.<br>
--paulr<br>
<br>
______________________________<wbr>_________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>
______________________________<wbr>_________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>