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

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

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

Redefining a term "xyz-none" to mean "xyz-sometimes" feels
wrong.
If you want an attribute that means "optsometimes" then it should
be a new attribute, with a name that reflects its actual semantics.
I am not opposed to that, but my understanding is that we have been
arguing about the definition of the existing attribute.
> 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.

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

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.

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 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?

Thanks,
--paulr

On Thu, Apr 22, 2021 at 11:40 AM <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.
>
> The word "none" means "none."  It does not mean
"sometimes."  Can we
> agree on that much?
>
> Redefining a term "xyz-none" to mean "xyz-sometimes"
feels wrong.
> If you want an attribute that means "optsometimes" then it should
> be a new attribute, with a name that reflects its actual semantics.
> I am not opposed to that, but my understanding is that we have been
> arguing about the definition of the existing attribute.
>
> > 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.
>
> LLVM does not have a way to not-optimize part of a function, so we
> achieve the goal by not inlining `optnone` functions.
>
> 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.
>
> 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 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?
Most of this is a pretty academic discussion - and probably more
heat/angst/difficulty than is needed right now, as much as I do care
about both perspectives (orthogonality of features V usability for the
common case).

I'm going to add noipa, and I'm going to wire it up to optnone in
clang. It's possible one of two things happen there: Either we wire up
noipa the same way noinline is (optnone /requires/ noinline now, and
so it'd /require/ noipa) or we change LLVM IR to remove that
constraint/tie between optnone and noinline, and add noipa in that way
too. (the third option of having optnone require one but not both of
these attributes isn't a state I'd want to get in) - though clang -O0
and clang __attribute__((optnone)) would both still lower to
optnone+noinline+noipa regardless of whether LLVM enforces the
connection between them or not.

- Dave

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
>