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

[Johannes Doerfert via llvm-dev]

On 4/22/21 11:44 AM, paul.robinson at sony.com wrote:
>> 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`?

`optnone`  -> make sure the code in this symbol is not optimized.
`noinline` -> make sure the code in this symbol is not copied
               into another symbol.

Two separate ideas, if you want both, use both attributes,
nobody argues against that use case. See below for a "real world"
use case.


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

Now you bring in the C level. I explicitly, and multiple times,
said I argue on IR level. If you want C `__attribute__((optnone))`
to imply `noinline`, that would be fine with me. However, on
IR level there is no reason to tie them together.

Even on C it is not clear. Think of a context sensitive problem
in a large application. You want pristine code for some calling
contexts but fast code for others. Right now, there is no way to
do that, except maybe using `__attribute__((flatten))` on all
callees that need to be fast. However, once you decoupled the two
attributes you can say that for some call sites you don't want it
to be inlined but for others you do. The ones you don't want to
inline the function are probably `optnone` themselves, so there is
no inlining happening anyway, no need to say anything special for
them.


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

I'd assume coders are capable of understanding the difference
between `optnone` and `noinline` and how they compose. That said,
I am only arguing on the IR level anyway and the conversation what
`__attribute__((optnone))` should be is a different one.


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

No worries.

~ Johannes


> --paulr
>