[llvm-dev] Revisiting/refining the definition of optnone with interprocedural transformations

[via llvm-dev]

> Let's look at an example. I show it in C but what I am arguing
> about is still IR, as described earlier, C is different.
> 
> ```
> __attribute__((optnone))
> void foo() { ... }
> __attribute__((optnone, noinline))
> void bar() { foo(); ... }
> void baz() { foo(); bar(); ... }
> ```
> Here, the user has utilized optnone and noinline to get different
> kinds of distinct effects that you could all want:
>   - foo is not optimized, not inlined into bar, but inlined into baz

foo's non-inlined instance is not optimized; but, the instance that
is inlined into baz *is* optimized.  How does that obey `optnone`?

>   - bar is not optimized and not inlined into baz
> 
> I hope this makes sense.
> 
> ~ Johannes

The use-case for `optnone` is to allow selectively not-optimizing
a function, which I've seen used only to permit better debugging
of that function.  Inlining optimizes (some instances of) the 
function, against the coder's express wishes, and interfering with 
the better debugging enabled by not-optimizing.  I don't see how 
that is beneficial to the coder, or any other use-case.  If you
have a practical use-case I would love to hear it.

Yes, I do see that separating the concerns allows this weird case
of a sometimes-optimized function, but I don't see any benefit.
Certainly it would be super confusing to the coder, and at the
Clang level I would strenuously oppose decoupling these.

Apologies for mentioning Attributor; I have no idea how it works,
and I was rather idly speculating why you want to decouple the
optnone and noinline attributes.
--paulr