[Bug tree-optimization/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled

["torvalds@linux-foundation.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552

--- Comment #43 from Linus Torvalds <torvalds@linux-foundation.org> ---
(In reply to Richard Biener from comment #42)
> 
> I think if we want to avoid doing optimizations on gcov counters we should
> make them volatile. 

Honestly, that sounds like the cleanest and safest option to me.

That said, with the gcov counters apparently also being 64-bit, I suspect it
will create some truly horrid code generation.

Presumably you'd end up getting a lot of load-load-add-adc-store-store
instruction patterns, which is not just six instructions when just two should
do - it also uses up two registers.

So while it sounds like the simplest and safest model, maybe it just makes code
generation too unbearably bad?

Maybe nobody who uses gcov would care. But I suspect it might be quite the big
performance regression, to the point where even people who thought they don't
care will go "that's a bit much".

I wonder if there is some half-way solution that would allow at least a
load-add-store-load-adc-store instruction sequence, which would then mean (a)
one less register wasted and (b) potentially allow some peephole optimization
turning it into just a addmem-adcmem instruction pair.

Turning just the one of the memops into a volatile access might be enough (eg
just the load, but not the store?)