On Fri, 9 Feb 2024 at 20:23, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Can it reorder the loads of const member wrt e.g. barrier()?
As far as I know, a C compiler can *not* in any situation think that
"const" means that something is immutable.
In C, a pointer to a "const' thing means that you are not allowed to
modify the object through *that* pointer, but it does not mean that
there might not be another non-const pointer that aliases the same
object.
Now, things are a bit different if the object definition itself is
"const", in that then there is generally no way for such an alias to
happen.
But anything that gets a pointer to a data structure that has a const
member cannot in the general case know whether there might be another
pointer somewhere else that could change said member.
IOW, 'const' - despite the name - does not mean "this field is
constant". It literally means "you can't write through this field".
And then as a very special case of that, if the compiler can show that
there are no possible aliases, the compiler can treat it as a constant
value.
The "no aliases" knowledge might be because the compiler itself
generates the object (eg an automatic variable), but it might also be
through things like "restrict" where the programmer has told the
compiler that no aliases exist.
But when it is a part of a union, by *definition* there are aliases to
the same field, and they may not be const.
End result: a compiler cannot validly hoist the load across the
spin_lock, because as far as the compiler knows, the spinlock could
change the value. 'const' in no way means 'the value cannot change'.
Of course, who knows what bugs can exist, but this is fairly
fundamental. I don't believe a C compiler can possibly get this wrong
and call itself a C compiler.
Linus
