4 ms·

I had no idea about this, I had mostly assumed that a decent compiler would do this. There is no reason this can't be implemented in the future, right?

by aktau 12y ago

cwzwarich 12y ago
It is difficult to implement correctly because the rules for `restrict` in the spec are quite nonintuitive; it doesn't simply mean that the two pointers don't alias each other. The guarantee provided by owned pointers in Rust is stronger than that of `restrict` in C, so we should be able to propagate the must-not-alias constraints better upon inlining.
- bluecalm 12y ago
  This is very interesting! Do you have some code examples or deeper explanation of this by any chance ?
  - cwzwarich 12y ago
    Well, I'm not a C language lawyer myself, so I'm merely going off of what I have heard from people who are, but consider the following C function: bool f(int *restrict a, int *b, bool should_modify) { if (should_modify) { *a = b; } return a == b; } Does this function have defined behavior? It turns out that the C spec says that the aliasing restrictions imposed by `restrict` only apply if the memory object pointed to by the restricted pointer has an intervening modification in the scope of the `restrict`; otherwise, the pointers are allowed to alias. Therefore, this function does not have defined behavior for all inputs. If a and b point to valid memory objects and a != b, then the behavior of f is defined regardless of the value of should_modify. If a == b, then f only has defined behavior if should_modify is false. Yes, this is arguably insane, but it's also the spec.
- kibwen 12y ago
  In the interest of full disclosure, I should point out that the Rust compiler currently isn't conveying aliasing information to LLVM at all (or if it is, it's very minimal). If anyone's interested in implementing it, it would be both an interesting project and immediately catapult you into Rust godhood. :)

I had no idea about this, I had mostly assumed that a decent compiler would do this. There is no reason this can't be implemented in the future, right?

by aktau 12y ago

I had no idea about this, I had mostly assumed that a decent compiler would do this. There is no reason this can't be implemented in the future, right?

cwzwarich 12y ago

It is difficult to implement correctly because the rules for `restrict` in the spec are quite nonintuitive; it doesn't simply mean that the two pointers don't alias each other. The guarantee provided by owned pointers in Rust is stronger than that of `restrict` in C, so we should be able to propagate the must-not-alias constraints better upon inlining.

bluecalm 12y ago
This is very interesting! Do you have some code examples or deeper explanation of this by any chance ?
- cwzwarich 12y ago
  Well, I'm not a C language lawyer myself, so I'm merely going off of what I have heard from people who are, but consider the following C function: bool f(int *restrict a, int *b, bool should_modify) { if (should_modify) { *a = b; } return a == b; } Does this function have defined behavior? It turns out that the C spec says that the aliasing restrictions imposed by `restrict` only apply if the memory object pointed to by the restricted pointer has an intervening modification in the scope of the `restrict`; otherwise, the pointers are allowed to alias. Therefore, this function does not have defined behavior for all inputs. If a and b point to valid memory objects and a != b, then the behavior of f is defined regardless of the value of should_modify. If a == b, then f only has defined behavior if should_modify is false. Yes, this is arguably insane, but it's also the spec.
kibwen 12y ago
In the interest of full disclosure, I should point out that the Rust compiler currently isn't conveying aliasing information to LLVM at all (or if it is, it's very minimal). If anyone's interested in implementing it, it would be both an interesting project and immediately catapult you into Rust godhood. :)