[llvm-dev] Redefining optnone to help LTO

[Mehdi Amini via llvm-dev]

> On Jan 16, 2017, at 10:00 AM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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?

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).

However LTO has other uses than optimizations: for instance instrumentations that needs full program access.
One of them is CFI: http://clang.llvm.org/docs/ControlFlowIntegrity.html <http://clang.llvm.org/docs/ControlFlowIntegrity.html>
If you want to debug and rebuild only part of the program, CFI still requires to use LTO, IIUC.

— 
Mehdi



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170116/954421a2/attachment.html>