via llvm-dev
2021-Apr-22 19:06 UTC
[llvm-dev] Revisiting/refining the definition of optnone with interprocedural transformations
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!) 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
Johannes Doerfert via llvm-dev
2021-Apr-22 19:25 UTC
[llvm-dev] Revisiting/refining the definition of optnone with interprocedural transformations
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 >