1. 36

  2. 3

    Great seeing the breakdown of the intermediate states, made it a much easier read for someone like me who knows no rust.

    Does anyone know why this information does not successfully make it to the llvm backend? Is it in that &match (&size) section?

    1. 2

      Dug around a bit and it may be related to https://github.com/rust-lang/rust/issues/38941#issuecomment-271364923 and https://github.com/rust-lang/rust/issues/16515

      If rustc is marking &size readonly but not noalias then LLVM may be forced to assume that size could be written to through some alias.

      But I’ve never even played with Rust’s internals so this is pure guesswork.

      1. 1

        Yeah, that looks like a winner. If you think writes can come in from any preempted thread, then you’re gonna need to call load before everything. Will be digging in on your links, thank you so much!

    2. 1

      It makes me wonder whether it would be worth it to hand monomorphize performance critical code like this and duplicate it for every possible power of two and then switch on size to call one of these functions at runtime, to get the full optimization potential.

      If you profile your application and determine that’s actually valuable, yes absolutely.