Here is an annotated version of rustc's `--release --target aarch64-apple-darwin` assembly output, for the fast version of my code that runs in 500ms. Annotate

Here is an annotated version of rustc's `--release --target aarch64-apple-darwin` assembly output, for the fast version of my code that runs in 500ms. Annotated https://gist.github.com/cormacrelf/4b2b37d1d870377d548b3a32a3c7b26a https://gist.github.com/cormacrelf/4b2b37d1d870377d548b3a32a... and full Godbolt https://rust.godbolt.org/z/aKK4TEs3x https://rust.godbolt.org/z/aKK4TEs3x. You may be interested to see the LLVM Opt Pipeline, any of the green passes (non-zero diffs) that are called LoopUnrollPass or LoopVectorizePass. You can see that it does a couple of LoopUnrollPasses and LoopVectorizePasses. In the end it results in a transformation from something like this: for (uint32_t i = 0; i <= 0xffff; i++) { if (in range) acc += 1; } to u32x4 v1 = [1,2,3,4]; u32x4 v0 = [0,0,0,0], v5 = [0,0,0,0]; u32x4 v6, v7; uint32_t w8 = 0xfff8; do { v6 = v1 + [4,4,4,4]; v7 = v1 >= 0 && v1 <= 1; v6 = v6 >= 0 && v6 <= 1; v0 -= v7; // add 1 to each lane if lane was true in v7 v5 -= v6; // add 1 to each lane if lane was true in v6 v1 += [8,8,8,8]; w8 -= 8; } while (w8); return element_sum(v0 + v5); That is basically unrolled x8, and then the loop body is grouped into two groups of four vector ops. You also save a lot of time by vectorising the sum operation over 8 lanes. The only non-vector operations in the loop body are on the w8 counter. The ratio of real work to "increment checking" is 8x better, and because we unrolled multiple ops into the loop body, we were able to vectorise it and run it in parallel. Re "how does it know when it's finished?": it counts like normal, as you can see there, it uses a register to count iteration. Unrolling does not mean "completely eliminate the termination check" unless your heuristic/supplied unroll threshold is larger than the (known) number of iterations. It generally just does the termination check fewer times by taking bigger strides. It's like walking up stairs two at a time. The answer re compile-time-full-evaluation: compilers use heuristics and pattern matching, they don't automatically try compile time evaluation for things they don't recognise. Nobody would have bothered to write a heuristic to detect "count floating point values in range" and eval it. There is no compiler pass to arbitrarily try to execute eveything in your program at compile time that's remotely possible.