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

[via llvm-dev]

> 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