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

Tue Oct 6 03:05:40 PDT 2020

nlopes added a comment.

My meta-comment about this patch is that I'm not sure LangRef is the right place for this content. I see LangRef as the stuff that is set in stone, not necessarily for ongoing discussions.
However, since LangRef doesn't get these bits right, it might be ok to have a warning section about stuff that is disputed/under discussion so that readers know that part is not set in stone.

================
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
----------------
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.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88860