[llvm-dev] Revisiting/refining the definition of optnone with interprocedural transformations
Johannes Doerfert via llvm-dev
llvm-dev at lists.llvm.org
Thu Apr 22 08:42:21 PDT 2021
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
More information about the llvm-dev
mailing list