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

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

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