On Wed, 27 Mar 2024 at 12:41, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote:
>
> _But_: the lack of any aliasing guarantees means that writing through
> any pointer can invalidate practically anything, and this is a real
> problem.
It's actually much less of a problem than you make it out to be.
A lot of common aliasing information is statically visible (offsets
off the same struct pointer etc).
The big problems tend to be
(a) old in-order hardware that really wants the compiler to schedule
memory operations
(b) vectorization and HPC
and honestly, (a) is irrelevant, and (b) is where 'restrict' and
actual real vector extensions come in. In fact, the type-based
aliasing often doesn't help (because you have arrays of the same FP
types), and so you really just need to tell the compiler that your
arrays are disjoint.
Yes, yes, possible aliasing means that the compiler won't generate
nice-looking code in many situations and will end up reloading values
from memory etc.
AND NONE OF THAT MATTERS IN REALITY.
Performance issues to a close approximation come from cache misses and
branch mispredicts. The aliasing issue just isn't the horrendous issue
people claim it is. It's most *definitely* not worth the absolute
garbage that is C type-based aliasing.
And yes, I do think it might be nice to have a nicer 'restrict' model,
because yes, I look at the generated asm and I see the silly code
generation too. But describing aliasing sanely in general is just hard
(both for humans _and_ for some sane machine interface), and it's very
very seldom worth the pain.
Linus
