Re: static_branch/jump_label vs branch merging

[Peter Zijlstra]

On Thu, Apr 22, 2021 at 12:08:20PM -0500, Segher Boessenkool wrote:
> On Thu, Apr 22, 2021 at 01:48:39PM +0200, Peter Zijlstra wrote:
> > Can we please have a __pure__ attribute that is prescriptive and not a
> > hint the compiler is free to ignore for $raisins ?
> 
> What does that mean?  What actual semantics do you want it to have?

I want a function marked as pure to be treated as such, unconditionally.

> The "pure" attribute means the compiler can assume this function does
> not have side effects.  But in general (and in practice in many cases)
> there is no way the compiler can actually check that, if that is what
> you were asking for.

Right, so currently the pure attribute gets ignored by the compiler
because of various reasons, one of them being an asm volatile ("") being
present somewhere inside it (AFAIU).

This means the compiler will emit multiple calls to the function, which
casuses loss in optimization possibilities; we've had
branch-eleminiation and hoisting as practical examples now.

That is; AFAICT the compiler sees the pure attribute and decides it was
wrongly applied because it cannot tell what the asm is doing; I want
that reversed such that it will assume the asm abides by the pure.

Does this mean we can have invalid code generation when we faultily
mark things pure? Yes, but then it's our own damn fault for sticking on
pure in the first place.

In short; I want pure (or really_pure if you want a second attribute) to
be a do-what-I-tell-you-already and not a
only-if-you-think-you-can-prove-I-didn't-make-a-mistake kinda knob. A
little bit like inline vs always_inline.

> And any such checking will depend on optimisation level and related
> flags, making that a no-go anyway.

Realistically I'm only bothered about -O2 and up since that's what we
build the kernel with. Obviously one doesn't care about optimizations
being lost when build with -O0.