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

On 4/21/21 9:29 PM, David Blaikie wrote:
>
>>> I'll see about posting an implementation of noipa and switching
>>> __attribute__((optnone)) over to lower to LLVM's optnone+noipa
rather
>>> than optnone+noinline.
>> FWIW, I think `noipa` should not imply `noinline`, unsure if you
>> had that in mind or not.
> Do you think it should require that noipa also carries noinline? (the
> way optnone currently requires noinline) Or should we let the
> non-inlining fall out naturally from the non-exact definition
> property?
>
So, non-exact definitions do not prevent inlining. You can even
create an internal copy and use that for IPO, think of it as
"inline-then-outline".

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

Circling back to `noipa`, I'm very much in favor of letting it
compose freely with the others, at least in the IR. So, it does
not require, nor imply `noinline` or `optnone`. Similarly,
`noinline` does not imply `noipa`, neither does `optnone`. The
latter might be surprising but I imagine I can use function
attributes of an `optnone` function at the call site but I will
not if the function is `noipa`.

Others might have different opinions though.

~ Johannes

> 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