better wording

[web.git] / ralf / _posts / 2020-12-14-provenance.md

diff --git a/ralf/_posts/2020-12-14-provenance.md b/ralf/_posts/2020-12-14-provenance.md
index 695e00a7e9e2e53e44f8e47e525d250e3af27693..bb2faed3c8678b38615cff4660c5e7e6dbc41525 100644 (file)
--- 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 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.
+But we know that the integer values computed by `(uintptr_t)(p+1)` and `(uintptr_t)q` (i.e., the bit pattern as stored 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.