← Back to context

Comment by Asooka

3 days ago

While I can't name the product I work on, we also use -fno-strict-aliasing. The problem with these optimisations is that they can only be done safely if you can prove aliasing never happens, which is equivalent to solving the halting problem in C++. In Rust I suspect the stronger type system can actually prove that aliasing doesn't happen in select cases. In any case, I can always manually do the optimisations enabled by strict aliasing in hot code, but I can never undo a customer losing data due to miscompilation.

> actually prove that aliasing doesn't happen in select cases

In the safe subset of Rust it's guaranteed in all cases. Even across libraries. Even in multi-threaded code.

  • To elaborate on that some more, safe Rust can guarantee that mutable aliasing never happens, without solving the halting program, because it forbids some programs that could've been considered legal. Here's an example of a function that's allowed:

        fn foo() {
            let mut x = 42;
            let mut mutable_references = Vec::new();
            let test: bool = rand::random();
            if test {
                mutable_references.push(&mut x);
            } else {
                mutable_references.push(&mut x);
            }
        }
    

    Because only one if/else branch is ever allowed to execute, the compiler can see "lexically" that only one mutable reference to `x` is created, and `foo` compiles. But this other function that's "obviously" equivalent doesn't compile:

        fn bar() {
            let mut x = 42;
            let mut mutable_references = Vec::new();
            let test: bool = rand::random();
            if test {
                mutable_references.push(&mut x);
            }
            if !test {
                mutable_references.push(&mut x); // error: cannot borrow `x` as mutable more than once at a time
            }
        }
    

    The Rust compiler doesn't do the analysis necessary to see that only one of those branches can execute, so it conservatively assumes that both of them can, and it refuses to compile `bar`. To do things like `bar`, you have to either refactor them to look more like `foo`, or else you have to use `unsafe` code.

  • It requires that the libraries you use do not have UB. If you have no unsafe, but your library does, you can get UB.

    https://github.com/rust-lang/rust/pull/139553

    This is why it may be a good idea to run MIRI on your Rust code, even when it has no unsafe, since a library like Rust stdlib might have UB.

    • Isn't this a pretty trivial observation, though? All code everywhere relies on the absence of UB. The strength of Rust comes from the astronomically better tools to avoid UB, including Miri.

      2 replies →

> which is equivalent to solving the halting problem

Most worthwhile undefined behaviour is. If the compiler could tell whether it was happening or not, it would be defined as an error. Surely detecting whether a tree borrow violation happens is also equivalent to solving the halting problem?