Messages in this thread | | | From | Nick Desaulniers <> | Date | Fri, 9 Apr 2021 12:33:29 -0700 | Subject | Re: static_branch/jump_label vs branch merging |
| |
On Fri, Apr 9, 2021 at 4:18 AM Peter Zijlstra <peterz@infradead.org> wrote: > > On Fri, Apr 09, 2021 at 12:55:18PM +0200, Florian Weimer wrote: > > * Ard Biesheuvel: > > > > > Wouldn't that require the compiler to interpret the contents of the > > > asm() block? > > > > Yes and no. It would require proper toolchain support, so in this case > > a new ELF relocation type, with compiler, assembler, and linker support > > to generate those relocations and process them. As far as I understand > > it, the kernel doesn't do things this way. > > I don't think that all is needed. All we need is for the compiler to > recognise that: > > if (cond) { > stmt-A; > } > if (cond) { > stmt-B; > } > > both cond are equivalent and hence can merge the blocks like: > > if (cond) { > stmt-A; > stmt-B; > } > > But because @cond is some super opaque asm crap, the compiler throws up > it's imaginry hands and says it cannot possibly tell and leaves them as > is.
Right, because if `cond` has side effects (such as is implied by asm statements that are volatile qualified), suddenly those side effects would only occur once whereas previously they occurred twice.
Since asm goto is implicitly volatile qualified, it sounds like removing the implicit volatile qualifier from asm goto might help? Then if there were side effects but you forgot to inform the compiler that there were via an explicit volatile qualifier, and it performed the suggested merge, oh well. -- Thanks, ~Nick Desaulniers
| |