From 37194bb7593c2858b6a10b3bffbaa8e1a8841f59 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 14 Dec 2020 18:53:27 +0100 Subject: [PATCH 1/1] fix int->uintptr_t fallout --- ralf/_posts/2020-12-14-provenance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ralf/_posts/2020-12-14-provenance.md b/ralf/_posts/2020-12-14-provenance.md index 9d4ef2c..695e00a 100644 --- a/ralf/_posts/2020-12-14-provenance.md +++ b/ralf/_posts/2020-12-14-provenance.md @@ -187,7 +187,7 @@ The second optimization gives us a clue into this aspect of LLVM IR semantics: c To see why, consider the two expressions `(char*)(uintptr_t)(p+1)` and `(char*)(uintptr_t)q`: if the optimization of removing pointer-integer-pointer roundtrips is correct, the first operation will output `p+1` and the second will output `q`, which we just established are two different pointers (they differ in their provenance). The only way to explain this is to say that the input to the `(char*)` cast is different, since the program state is otherwise identical in both cases. -But we know that the integer values computed by `(uintptr_t)(p+1)` and `(uintptr_t)q` (i.e., the bit pattern of length 32 that serve as input to the `(char*)` casts) are the same, and hence a difference can only arise if these integers consist of more than just this bit pattern---just like pointers, integers have provenance. +But we know that the integer values computed by `(uintptr_t)(p+1)` and `(uintptr_t)q` (i.e., the bit pattern as represented in some CPU register) are the same, and hence a difference can only arise if these integers consist of more than just this bit pattern---just like pointers, integers have provenance. Finally, let us consider the first optimization. Here, a successful equality test `iq == ip` prompts the optimizer to replace one value by the other. -- 2.30.2