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

[via llvm-dev]

> There seems to be a bunch of confusion and probably some
> conflation/ambiguity about whether we're talking about IR constructs
> on the C attributes.
> 
> Johannes - I assume your claim is restricted mostly to the IR? That
> having optnone not require or imply noinline improves orthogonality of
> features and that there are reasonable use cases where one might want
> optnone while allowing inlining (of the optnone function) or optnone
> while disallowing inlining (of the optnone function)

Even at the IR level, I'd argue that inlining a function marked optnone
is violating the contract that the function should not be optimized;
because once it's inlined somewhere else, there's no control over the
optimization applied to the inlined instance.

Not to say we couldn't redefine the IR optnone that way, but it really
feels wrong to have 'optnone' actually mean 'optsometimes'.

> Paul - I think you're mostly thinking about/interested in the specific
> source level/end user use case that motivated the initial
> implementation of optnone. Where, I tend to agree - inlining an
> optnone function is not advantageous to the user. Though it's possible
> Johannes 's argument could be generalized from IR to C and still
> apply: orthogonal features are more powerful and the user can always
> compose them together to get what they want. (good chance they're
> using attributes behind macros for ease of use anyway - they're a bit
> verbose to write by hand all the time)

I'm obviously finding it hard to imagine a real use-case for that...
I mean, sure you can lay out cases and say in a rather theoretical
way, here's this interesting thing that happens when you do this.
Interesting things are interesting, but are they practical/useful?
Any non-speculative, real-world applications?  The YAGNI principle 
applies here.

(I believe the original inspiration was an MSVC feature, actually.)

As long as the existing Clang __attribute((optnone)) semantics don't
change (i.e., continued to imply noinline) it won't affect my users;
but I would *really* not want to change something like that on them,
without a bonafide use-case that could be readily explained.

Here's a real-world case that might help explain my resistance.
Sony has a downstream feature that allows suppressing debug-info for
inlined functions; the argument is that these are generally small,
easily verifiable, and debugging sessions that keep popping down into
them are annoying and distracting from looking at the real problem.

Our initial implementation depending on whether the function was
actually inlined.  For one thing, it was easy to identify inlined
scopes, and just not emit them.  However, this was a terrible user
experience, because whether step-in did or didn't happen was dependent
on how the optimizer happened to feel that day.  Programmers had no
control over their debugging experience.

We changed this so that programmers could tell, by looking at their
source code, whether debug info would be suppressed.  In effect it's
a command-line option that implicitly adds 'nodebug' to a given set
of cases (methods defined in-class, 'inline' keyword).

So, anything that smacks of "you get different things depending on
whether the compiler decided to inline your function" just makes me
twitch.

And that's what the "optnone doesn't mean noinline" proposal does.

> There's also the -O0 use of optnone these days (clang puts optnone on
> all functions when compiling with -O0 - the intent being to treat such
> functions as though they were compiled in a separate object file
> without optimizations (that's me projecting what I /think/ the mental
> model should be) - which, similarly, I think will probably want to
> keep the current behavior (no ipa/inlining and no optimization -
> however that's phrased).

The -O0 case was so that you can mix -O0 with LTO and have it stick.
Your as-if seems like a reasonable model for it.

Thanks,
--paulr