From ef489949c6d6d70bd9c618ee1cac919a9e5f5593 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 16 Jul 2020 12:05:51 +0200 Subject: [PATCH 1/1] mention speculative execution --- ralf/_posts/2020-07-15-unused-data.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ralf/_posts/2020-07-15-unused-data.md b/ralf/_posts/2020-07-15-unused-data.md index b9b51b1..500ecef 100644 --- a/ralf/_posts/2020-07-15-unused-data.md +++ b/ralf/_posts/2020-07-15-unused-data.md @@ -74,7 +74,9 @@ Before the optimization, that call was fine. After the optimization, that call is UB because we are doing `if b` where `b` is `3`. This is because loop-invariant code motion makes dead code live when the loop is not actually executed. -To fix this, we could require the compiler to prove that the loop runs at least once, but in general that will be hard (and in `example` it is impossible, since `num` can indeed be `0`). +(We can think of this as a form of "speculative execution", though entirely unrelated to CPU-level speculative execution.) +To fix the optimization, we could require the compiler to prove that the loop runs at least once (i.e., we could avoid speculative execution), but in general that will be hard (and in `example` it is impossible, since `num` can indeed be `0`). +Another option is to restructure the code to only compute `incr` if `num > 0`, but again this can be hard to do in general. So the alternative that Rust uses is to require that even "unused" data satisfies some basic validity. That makes `example(transmute(3u8), 0)` UB in *both* versions of `example`, and as such the optimization is correct for this input (and indeed for all possible inputs). -- 2.30.2