[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Chandler Carruth via Phabricator via cfe-commits]

chandlerc added a comment.

In https://reviews.llvm.org/D28404#641696, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28404#641632, @probinson wrote:
>
> > In https://reviews.llvm.org/D28404#641606, @mehdi_amini wrote:
> >
> > > If we want to support `-O0 -flto` and `optnone` it the way to convey this to the optimizer, I don't see the alternative.
> >
> >
> > optsize != -Os (according to Chandler)
> >  minsize != -Oz (according to Chandler)
> >  optnone != -O0 (according to both me and Chandler)
>
>
> Of course, but that's just an implementation limitation, mostly for historical reason I believe, not by design.


There is certainly a lot of history here influencing this, but I think there is also some a  fundamental difference. The flag is a request from the user to behave in a particular way. The LLVM attribute is a tool we use in some cases to try to satisfy that request.

When we're not doing LTO, it is easier to satisfy the requests of '-O' flags. The fact that we happen to not use attributes to do it today is just an implementation detail.

When we are doing LTO, satisfying different requests is hard. We should do our best, but I think it is reasonable to explain to the user that "with LTO, we can't fail to optimize with the Wombat optimization because of <reasons> when one file requests -O0 and another requests -O2". Same thing for the other levels.

This seems precisely analogous to the fact that even when the user requests -O0, we will do some inlining. Why? Because we *have to* for semantic reasons.

So I think what Mehdi is driving at is that if '-O0 -flto' has a mismatch from '-O0' in terms of what users expect, we should probably try to fix that. I'd suggest that there may be fundamental things we can't fix and that is OK. I don't think this is unprincipled either, we're doing the best we can to honor the user's request.

The other thing that might help is to point out that there *are* principles behind why these flags. 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.

If we ever want to really push on -Og, that might indeed require an attribute to distinguish it.

>> optnone is not "the way to convey (-O0) to the optimizer."

So, I view '-O0' as a request from the programmer to turn off the optimizer to the extent possible and give them as naive, minimally transformed representation of th ecode as possible.

And based on that, I view optnone as a tool to implement precisely these semantics at a fine granularity and with survivability across bitcode roundtrip.

It just isn't the *only* tool, and sometimes we can use an easier (and cheaper to Mehdi's compile time point) tool.

I think the text for spec'ing optnone in the LLVM langref needs to be updated to reflect this though. Currently it says:

> This function attribute indicates that most optimization passes will skip this function, with the exception of interprocedural optimization passes.

This is demonstrably false:

  % ag OptimizeNone lib/Transforms/IPO
  lib/Transforms/IPO/ForceFunctionAttrs.cpp
  47:      .Case("optnone", Attribute::OptimizeNone)
  
  lib/Transforms/IPO/Inliner.cpp
  813:    if (F.hasFnAttribute(Attribute::OptimizeNone))
  
  lib/Transforms/IPO/InferFunctionAttrs.cpp
  30:    if (F.isDeclaration() && !F.hasFnAttribute((Attribute::OptimizeNone)))
  
  lib/Transforms/IPO/FunctionAttrs.cpp
  1056:    if (F.hasFnAttribute(Attribute::OptimizeNone)) {
  1137:    if (!F || F->hasFnAttribute(Attribute::OptimizeNone)) {

I'll send a patch.


https://reviews.llvm.org/D28404