[PATCH] D88860: [LangRef] Describe why the pointer aliasing rules are currently unsound.

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
Comment at: llvm/docs/LangRef.rst:2586
+preserve something roughly equivalent to "based on".  The problem here is
+the current "inbounds" allows pointers one byte past the end of an object; that
+pointer could point to another object, so analyzing that is a lot more
----------------
nlopes wrote:
> my understanding is that for C we need to allow a pointer to be at the end of the object (not past, just at the end; you can't dereference it still). This is, for example, because of loops that increment pointers and check them against the end ptr.
> 
> That end pointer can have the same underlying machine value as the beginning of another object, thus making inttoptr complicated.
> If the allocator guaranteed that this case didn't happen, it would make things easier, but for small objects that's probably a big penalty. And LLVM can't assume that would hold for custom allocators.
> 
> We support this semantics of control-flow contributing to the aliasing of an inttoptr result. To fold `inttoptr(ptrtoint(ptr)) -> ptr` one needs to prove that ptr is dereferenceable though.
> my understanding is that for C we need to allow a pointer to be at the end of the object

Well, for pointers we know are dereferenced, we could mark up the GEPs more aggressively.  But yes, that's where this sort of model breaks down.

> To fold inttoptr(ptrtoint(ptr)) -> ptr one needs to prove that ptr is dereferenceable though.

I guess if you have load(inttoptr(ptrtoint(ptr))), you can optimize that to load(ptr) if ptr is dereferenceable: the load would be UB if it wasn't equivalent.  I don't think it helps more generally, though.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88860/new/

https://reviews.llvm.org/D88860