Messages in this thread | | | Date | Thu, 22 Apr 2021 19:49:23 +0200 | From | Peter Zijlstra <> | Subject | Re: static_branch/jump_label vs branch merging |
| |
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.
| |