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

[via llvm-dev]

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