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

[Johannes Doerfert via llvm-dev]

On 4/22/21 2:06 PM, paul.robinson at sony.com wrote:
> Because I put my constructive suggestion at the end of a long
> email, I'll repeat it with more clarity here:
>
> `optnone` is what it is.
>
> Define a new `opt-sometimes` that means what Johannes suggests.
> (A better name is more than welcome!)

The point is, I never suggested to change the meaning of
`optnone` (in IR). I argue to change the requirement for
it to always go with `noinline`. `optnone` itself is not
changed, you get exactly the same behavior you got before,
and `noinline` is also not changed. They are simply not
required to go together.

If you look at the uses of `optnone` in LLVM, you will not
find the passes to look for `noinline` as well, nor do they
need to. The decision to (not) act is based on `optnone`,
which it not changed at all.

~ Johannes


> Clang's __attribute__((optnone)) can migrate to meaning
> { opt-sometimes, noipa, noinline }.
>
> `optnone` can be retired, existing only in the bitcode upgrader
> which replaces it with { opt-sometimes, noipa, noinline }.
>
> Changing Clang's attribute to mean something else can be put off
> to another day.
> --paulr
>