3 ms·

1. Rust has proper references with much stricter aliasing requirements. So no, it would be C that would slow down. Rust would still be able to take advantage of

1. Rust has proper references with much stricter aliasing requirements. So no, it would be C that would slow down. Rust would still be able to take advantage of these optimisations. 2. In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value if there has been any other pointers access in between. The compiler also cannot reorder any statements with pointer accesses. They would basically behave as memory barriers (if I understand them correctly). That will cause slow downs in runtime (the compile time will speed up though). 3. Sure. Perhaps that is an option. I wouldn't call it a flag to "break program" though. Maybe a config file that tells the compiler which assumptions can be made (strict aliasing, associative floats, threading safe, etc). EDIT: In point 3, I would also add assumptions like whether the code can be changed at runtime, etc (take a pointer to a function then write your own code there).

dataflow 2y ago
> In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value if there has been any other pointers access in between. I have no idea what you mean. The whole point of this discussion is that the example in the article should not be optimized in the manner they're describing, because it would be wrong. That is... a good thing. Not a bad thing. And the compiler certainly could replace a pointer access with its value if there has been other pointer access in between, as long as that pointer wasn't leaked away into some opaque place via an integer. > The compiler also cannot reorder any statements with pointer accesses. They would basically behave as memory barriers (if I understand them correctly). No, I don't think you understood what I'm saying. See above. It would still be perfectly legal for the compiler to transform char p[1] = {0}; opaque(); return p[0]; to opaque(); return 0; under what I wrote above, the intervening statement notwithstanding.

dataflow 2y ago

> In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value if there has been any other pointers access in between. I have no idea what you mean. The whole point of this discussion is that the example in the article should not be optimized in the manner they're describing, because it would be wrong. That is... a good thing. Not a bad thing. And the compiler certainly could replace a pointer access with its value if there has been other pointer access in between, as long as that pointer wasn't leaked away into some opaque place via an integer. > The compiler also cannot reorder any statements with pointer accesses. They would basically behave as memory barriers (if I understand them correctly). No, I don't think you understood what I'm saying. See above. It would still be perfectly legal for the compiler to transform char p[1] = {0}; opaque(); return p[0]; to opaque(); return 0; under what I wrote above, the intervening statement notwithstanding.