<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_-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><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><br></div><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). 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><br></div><div>I'm just trying to understand the bigger picture here.</div><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_-2478622514022924654HOEnZb"><font color="#888888"><div>Mehdi</div></font></span><div><div class="m_-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>