llvm dev - Apr 2021 - Revisiting/refining the definition of optnone with interprocedural transformations

> That said, I believe it is a mistake that `optnone` requires
> `noinline`. There is no reason for it to do so on the IR level.
> If you argue C-level `optnone` should imply `noinline`, that is
> a something worth discussing, though on the IR level we can
> decouple them. Use case, for example, the not-optimized version
> is called from functions that are `optnone` themselves while
> other call sites are inlined and your function is optimized. So
> you can use the two attributes to do context sensitive `optnone`.
The original intent for `optnone` was to imitate the -O0 pipeline
to the extent that was feasible.  The -O0 pipeline (as constructed
by Clang) runs just the always-inliner, not the regular inliner;
so, functions marked `optnone` should not be inlined.  The way
to achieve that effect most simply is to have `optnone` require
`noinline` and that's what we did.

If we have `optnone` stop requiring `noinline` and teach the 
inliner to inline an `optnone` callee only into an `optnone` caller,
then we are violating the intent that `optnone` imitate -O0, because
that inlining would not have happened at -O0.

--paulr

On 4/22/21 9:43 AM, paul.robinson at sony.com wrote:
>> That said, I believe it is a mistake that `optnone` requires
>> `noinline`. There is no reason for it to do so on the IR level.
>> If you argue C-level `optnone` should imply `noinline`, that is
>> a something worth discussing, though on the IR level we can
>> decouple them. Use case, for example, the not-optimized version
>> is called from functions that are `optnone` themselves while
>> other call sites are inlined and your function is optimized. So
>> you can use the two attributes to do context sensitive `optnone`.
> The original intent for `optnone` was to imitate the -O0 pipeline
> to the extent that was feasible.  The -O0 pipeline (as constructed
> by Clang) runs just the always-inliner, not the regular inliner;
> so, functions marked `optnone` should not be inlined.  The way
> to achieve that effect most simply is to have `optnone` require
> `noinline` and that's what we did.
>
> If we have `optnone` stop requiring `noinline` and teach the
> inliner to inline an `optnone` callee only into an `optnone` caller,
> then we are violating the intent that `optnone` imitate -O0, because
> that inlining would not have happened at -O0.
I think I initially read this wrong, hence the part below.
After reading it again, I have one question: Why would the
inliner inline something that is not `always_inline` into
an `optnone` caller? That would violate the idea of `optnone`,
IMHO, regardless if the callee is `optnone` or not. That is
why I don't believe `noinline` on the callee is necessary
for your use case.

--- I misread and I wrote this, might be useful still ---

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
  - bar is not optimized and not inlined into baz

I hope this makes sense.

~ Johannes

> --paulr