<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 16, 2017, at 10:00 AM, Sean Silva via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""></div><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 class=""></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" class="">http://clang.llvm.org/docs/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><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class="">-- Sean Silva</div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jan 11, 2017 at 8:34 AM, Robinson, Paul via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><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 class="">
"I was compiled with -O0" in the IR, because it seems like a good idea to<br class="">
remember that fact in an LTO compilation and there is no way to remember<br class="">
that fact currently. A couple of people felt it might be better to have<br class="">
this idea discussed on the dev list, where it might get better exposure,<br class="">
so I'm volunteering to get that discussion started.<br class="">
<br class="">
While 'optnone' does cause lots of optimizations to bypass a function,<br class="">
exactly matching -O0 was not the motivation and never a hard requirement.<br class="">
The implementation makes a distinct effort to get close to the behavior<br class="">
of -O0, but it's not an exact match and for the intended purpose (allowing<br class="">
a given function to be un-optimized to help debugging) it worked fine.<br class="">
<br class="">
Using 'optnone' to convey -O0 to LTO is something of a redefinition, or<br class="">
at least a re-purposing, of the attribute. To get there from here, I<br class="">
think we would need a couple of things to happen, separately from the<br class="">
minor grunt work of adding 'optnone' to function IR at -O0.<br class="">
<br class="">
1) Update the LangRef definition of 'optnone' to reflect this intent.<br class="">
The current definition doesn't provide a motivation, and the description<br class="">
is (deliberately) a bit vague. If we want 'optnone' to intentionally<br class="">
match -O0, that should be tightened up.<br class="">
<br class="">
2) Make a concerted effort to teach 'optnone' to targets. Currently<br class="">
I know the X86 target is aware of it, but I'm not so sure about others.<br class="">
<br class="">
3) Take another look at what 'optnone' currently does *not* turn off,<br class="">
and see if there is something we can do about that. In some cases this<br class="">
will not be practical, and we may just have to live with that.<br class="">
<br class="">
(Okay, we need 3 things to happen.)<br class="">
<br class="">
I won't say this is blocking Mehdi's work, but it would remove a<br class="">
point of contention and allow the review to proceed more smoothly.<br class="">
--paulr<br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>