Restricted pointers (and the analogue with threads)

[lerno]

In C we can now use "restricted" to declare that a pointer cannot be aliased. I will try to argue that the "restricted" should be default and you should need to explicitly have to declare a pointer as not restricted.

My experience after both writing correct threaded code and fixing incorrectly written threaded code is that attempts to create an illusion of "this is now thread safe" without having to actually understand threading is doomed. Well meant things like the keyword "synchronized" or so-called "thread safe" libraries (that actually still required you to understand threading to use it properly in a multi-threaded environment) are increasingly understood to be a bad thing. These are leaky abstractions that often just makes things worse (creating deadlocks etc)

I suggest a similar approach for C2. Basically say that "in C2 all pointers are considered restricted, so if you want to tell ensure the data is always loaded from memory, you need to explicitly mark it so". This is, incidentally, pretty similar to how volatile works, so the same keyword could actually be reused.

[bas]

I have been programming in C for around 20 years, but I've never used the 'restricted' thing. The only time I actually ran into it
was when looking at libC's memcpy(). I can understand that it can be useful there.  Ideally we could just test the generated LLVM
IR code and then see how much (performance) difference it really makes.

There are some presentations by Andrew Kelly, the Zig language creator that describe how he checked the IR code that resulted
from different concepts. That's really cool to do.
 

[lerno]

It's fairly straightforward to try out different things using https://godbolt.org (e.g. https://godbolt.org/z/GpJ0UC)

There has been some benchmarking on PowerPC that I found, giving up to 30% faster code. However, this means the language still needs to be smart about it. Look at the problems mentioned here: https://blog.regehr.org/archives/1307

Aside from the situation of foo(&l, &l) where the user deliberately creates an aliasing issue, they need to be mitigated.

[lerno]

Several languages, including Fortran, uses the same behaviour as "restrict" by default.

As memory latency increases, the aliasing issue becomes more and more important. When C was conceived it was wholly unnecessary. Today it's becoming something very important and gives you the ability to be "faster than C".

Since restrict wasn't available until C99, it's not surprising that you haven't used it much. I haven't done as much C programming as you, but I didn't really notice it until I started reading up on heavily optimized game engines.

[bas]

Godbolt.org is very nice!

For developing an LLVM-based compiler, there are (roughly) 2 steps involved:
- the frontend (like Clang or C2c) generate LLVM IR (pseudo assembly)
- LLVM generates architecture specific instructions

Godbolt shows only the final end result. So generating 'better' IR might not necessarily result
in better Asm. Also using a new version of LLVM might generate better Asm based on the same
IR. So we need to look at both the IR that C2C generates And the Asm result (for a few common
architectures (eg. x86_64, Arm)

[lerno]

Yes, I mentioned this in the array proposal – depending on how we deal with aliasing/restrict then different ways of implementing arrays are also needed to detect aliasing.

[bas]

Yes the hard part is detecting whenever the strict aliasing rules are broken..