Hacker News Reader

Comment by coliveira | Hacker News Reader

The C language has provided the restrict keyword to solve these aliasing issues since the C99 standard. That is, 20 years ago.

View on HN

I think this generally doesn't have much of an impact on performance.

Just a personal anecdote, but it regularly makes a substantial (like 2x+) difference for me in tight linear algebra loops. It seems to be required if you want to coax clang to emit vfmad instructions for common C linear algebra idioms. Narrow use case, I know, but it can definitely make a big difference in some domains.

I'll take your word for it. I guess I live in a world where the code I see is rarely tight algebra loops, but I can see that in certain domains you would definitely care.

It certainly does... it's the main reason fortran was often faster than C, isn't it? Aliasing prevents automatic vectorization, among other things.

Whether or not the compiler will be smart enough to autovectorize is a different question.

The developer must also be smart enough not to do the mistake to lie to the compiler, by actually doing aliasing with restricted variables as it is UB and nasal dragons beware.

C compilers don't validate correct use of restrict.

Not all C compilers handle even correct uses of `restrict` properly. For about three years, Rust has been unable to use the LLVM equivalent of `restrict` when downleveling its references, because it keeps finding LLVM miscompilation bugs around it.

These LLVM bugs don't get noticed with C because C programs rarely use `restrict` as pervasively as a downleveled Rust program ends up doing.

I wonder if these same LLVM issues affect LLVM fortran attempts?

I feel like they would have to, if they were to produce a remotely competitive compiler. That's why I'm hoping NVidia's Flang[1] efforts will lead to this aspect of LLVM being cleaned up.

[1]: https://github.com/flang-compiler/flang

Reply on news.ycombinator.com