From eed0a4d0faba95bfef76957eb3e12ea2f55424cd Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 25 May 2022 10:08:28 +0200 Subject: [PATCH] note on integer-pointer transmutation --- ralf/_posts/2022-04-11-provenance-exposed.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ralf/_posts/2022-04-11-provenance-exposed.md b/ralf/_posts/2022-04-11-provenance-exposed.md index 6ab04f5..53d0b84 100644 --- a/ralf/_posts/2022-04-11-provenance-exposed.md +++ b/ralf/_posts/2022-04-11-provenance-exposed.md @@ -421,6 +421,10 @@ My personal stance is that we should not let the cast synthesize a new provenanc This would entirely lose the benefit I discussed above of making pointer-integer round-trips a *local* concern -- if these round-trips produce new, never-before-seen kinds of provenance, then the entire rest of the memory model has to define how it deals with those provenances. We already have no choice but treat pointer-integer casts as an operation with side-effects; let's just do the same with integer-pointer casts and remain sure that no matter what the aliasing rules are, they will work fine even in the presence of pointer-integer round-trips. +That said, under this model integer-pointer casts still have no side-effect, in the sense that just removing them (if their result is unused) is fine. +Hence, it *could* make sense to implicitly perform integer-pointer casts in some situations, like when an integer value (without provenance) is used in a pointer operation (due to an integer-to-pointer transmutation). +This breaks some optimizations like load fusion (turning two loads into one assumes the same provenance was picked both times), but most optimizations (in particular dead code elimination) are unaffected. + #### What about LLVM? I discussed above how my vision for Rust relates to the direction C is moving towards. -- 2.30.2