On Tue, Nov 05, 2024 at 06:41:24PM +0100, Richard Biener wrote:
> I don’t think it will matter in practice?
IMHO it will. Many projects have many inline asms, e.g. glibc several
hundreds of them, none of them need this treatment, many are used in leaf
functions, including really small functions which will be affected most.
Kernel has over 2000 volatile inline asms, and maybe it needs it on 10-20
from those (just guessing).
> What else should volatile be for and why should it exclude this particular
> side-effect that cannot be expressed by constraints? IMHO correctness
> trumps optimization here unless we want to retroactively document the red
> zone is off limits for any asm()?
volatile primarily means it won't be DCEd if the outputs are unused.
It doesn't imply a "memory" clobber, or clobbering of some other memory
like in this specific case.
GCC never disabled leaf functions because of volatile asms and the red-zone
vs. inline asm stuff isn't something that appeared in the last year, we've
been telling users about it 20 years ago, kernel is well aware of that, just
want some guaranteed way to mark it. Right now they probably use either
the rsp clobbering or __builtin_frame_address (0), both of which happen to
work but we want to move them from that. We don't really need to replace
it with nothing, the current way of requesting no red-zone can be replaced
with some other.
And if some other project suffers from this, they can do so as well.
This isn't a silent miscompilation that wouldn't show up for years, if
a function uses red-zone and something pushes something on the stack or even
calls some function which uses several stack slots below the return address
as well, one will see very quickly it doesn't work as expected.
Jakub
