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

[Johannes Doerfert via llvm-dev]

On 4/22/21 1:40 PM, paul.robinson at sony.com wrote:
>>> Not to say we couldn't redefine the IR optnone that way, but it really
>>> feels wrong to have 'optnone' actually mean 'optsometimes'.
>> It does not.
> A point of phrasing:  Please do not tell me how I feel.
> I say it feels wrong, and your denial does not help the conversation.

I feel you are interpreting my words in a way that makes them
sound worse than I would imagine outside observers do interpret
them, especially as they come with context and not as standalone
as it looks in your reply.

That said, I do not wish to tell you how you feel, should feel,
or anything else in that direction for that matter. If my words
come across as such, apologies. I will try to work on that.


>
> The word "none" means "none."  It does not mean "sometimes."  Can we
> agree on that much?

We can. Unsure why you would imagine I do not know the meaning of
"none" or "sometimes" for that matter. I think we can establish I
know basic words to avoid these kind of questions in the future :)


> Redefining a term "xyz-none" to mean "xyz-sometimes" feels wrong.

Agreed. I do not believe I'm proposing to do that.


> If you want an attribute that means "optsometimes" then it should
> be a new attribute, with a name that reflects its actual semantics.
Agreed. I am always in favor of attributes that have a single
specific meaning and a suitable name. I don't have a use case
for "optsomtimes" just yet but generally speaking I'm all for
composeable attributes that do not conflate ideas.


> I am not opposed to that, but my understanding is that we have been
> arguing about the definition of the existing attribute.

I don't think we do, especially since I do not think I want to
change the definition of `optnone`, at least the part that
all use cases in LLVM that I'm aware of are looking at. So, passes
would still be skipped if a function is `optnone` as the description
in the lang ref says. What would be different is that you have the
option, not the obligation, to pair it with `noinline`. If you do,
you get the `noinline` effect. If you don't, you don't. The `optnone`
effect stays the same either way.


>> Take `noinline` as an example. A `noinline` function
>> is not inlined, so far so good.
> And if the compiler decides it is useful to make copies/clones of
> the function, those aren't inlined either.  The copies retain their
> original attributes and semantics.  (Perhaps the compiler can make
> copies to take advantage of argument propagation, or some such.  I
> do not think this proposition is unreasonable.)
>
>> Now a caller of a `noinline`
>> function might be inlined all over the place anyway.
>> What I try to say is that function attributes apply to the function,
>> not to the rest of the world. If you want to say: do not optimize this
>> code ever, not here nor anywhere else, use `optnone` + `noinline`. If
>> you want to the function symbol to contain unoptimized code so
>> you can debug it, use `optnone`.
> You are making a severe distinction between the copy of the function
> that happens not to be inlined, and the copies that have been inlined,
> such that the inlined copies have lost their original properties.
> But just as the copies of the `noinline` function retain `noinline`
> and are not inlined, I argue that the `optnone` function copies ought
> to retain `optnone` and not be optimized.

If you want `optnone` functions to not be copied/inlined, use
`noinline`. We have an attribute for that and we literally require
it right now to get the effect you want. It is not `optnone` that
prevents copies which are then optimized, it is `noinline`. I do
not propose to change that one bit.


>
> LLVM does not have a way to not-optimize part of a function, so we
> achieve the goal by not inlining `optnone` functions.

Agreed.


>
> I dispute that the inlined copies of an `optnone` function should
> lose that much of their original characteristics, and the rest of
> the disagreement follows from there.  But I have a suggestion to
> offer below.
>
>
>> Let's take a step back for a second and assume we would have
>> always said `optnone` + `noinline` gives you exactly what you
>> get right now with `optnone`. I think we can explain that to
>> people, we can say, `optnone` will prevent optimization "inside
>> this symbol" and `noinline` will prevent the code to be copied
>> into another symbol. Every use case you have could be served by
>> adding these two attributes instead of the one you do now. Everyone
>> would be as happy as they are, all the benefits would be exactly
>> the same, no behavior change if you use the two together. That said,
>> it would open up the door for context sensitive debugging. Now you
>> can argue nobody will ever want to debug only a certain path through
>> their program, but I find that position requires a justification more
>> than the opposite which assumes people will find a way to benefit from
>> it.
> I don't think "inside this symbol" is meaningful to most programmers.
> They see methods/functions, and the internal operation of compilers
> (e.g., making copies of functions) are relatively mysterious.  I say
> this as someone who has spent many decades helping programmers use my
> compilers.
When I say symbol I mean function/method. So "inside this function
or method" is what I tried to say. People can deal with that concept.

> I don't dispute that you can invent a scenario where it could be useful;
> I reserve the right to be unpersuaded that it would occur often enough
> that people would think of and make use of the feature.

I don't claim people will jump on it, nor can I predict how many will
use it at all. What I'm saying it can be useful and that is by itself
a good enough reason (for me) to expose the functionality. Time, and
users, will tell us if they use it or not. Furthermore, I did say that
the C level can be untouched if we really want to, not that I'm in favor
of that but it is certainly a harder sell. The IR level change I am
advocating for is just a verifier condition, nothing else, it doesn't
even leak into the user space. I'm not sure why this is so controversial.


>
>> I totally think -O0 can imply all three attributes, optnone, noipa,
>> noinline.
> I totally think -O0 can imply { opt-sometimes, noipa, noinline }; and
> this combination can be an upgrade path away from the existing optnone.
>
> Can we proceed on that basis?

I don't know what `optsomtimes` is nor how it differentiates itself from
`optnone`. I'm also unsure why you would not go with `optnone`, `noinline`,
and `noipa` for -O0, isn't that exactly what you wanted to have all along?

~ Johannes


>
> Thanks,
> --paulr
>