* Jakub Jelinek: > Functionally, I think whether we do an 8-bit or 32-bit or 64-bit > or with 0 constant doesn't matter, we don't modify any values on the > stack, just pretend to modify it. The 8-bit and 32-bit ors > are 1-byte shorter though than 64-bit one. How the 3 behave > performance-wise is unknown, if the particular probed spot on the > stack hasn't been stored/read for a while and won't be for a while, > then I'd think it shouldn't matter, dunno if there can be store > forwarding effects if it has been e.g. written or read very recently > by some other function as say 32-bit access and now is 8-bit. The > access after the probe (if it happens soon enough) should be in valid > programs a store (and again, dunno if there can be issues if the > sizes are different).
I don't see a discussion in the code why a read-modify-write operation is used for probing. Maybe because a plain load would need an extra register? And a plain store could result in a valgrind false positive? But maybe we could use CMPL? The register version is one byte shorter than ORB, too. I think for -fstack-check, in may be desirable to trigger copy-on-write on some systems, but for -fstack-clash-protection, that does not seem necessary (no proactive triggering of stack overflow traps needed). Thanks, Florian
