[PATCH] D63525: LangRef: Attempt to formulate some rules for addrspacecast

[Matt Arsenault via Phabricator via llvm-commits]

arsenm added inline comments.


================
Comment at: llvm/docs/LangRef.rst:3047
+address spaces are target-specific. Memory access through an invalid,
+non-dereferenceable "null" pointer is undefined behavior in any address
+space. Pointers with the bit-value 0 are only assumed to be
----------------
nlopes wrote:
> efriedma wrote:
> > Given we don't define what it means for a pointer to be "null", or promise that such a pointer exists in every address-space, it isn't really meaningful to say that dereferencing null is undefined.  We can just drop that whole sentence, I think.
> agreed
I can drop the null part here, but I think the important part to note is dereferencing a non-dereferenceable pointer is still undefined behavior in any address space.

I would eventually like to move towards defining the null concept, rather than special casing address space 0.


================
Comment at: llvm/docs/LangRef.rst:3051
+
+If an object can be proven accessible through a pointer with a
+different address space, the access may be modified to use that
----------------
nlopes wrote:
> uhm, do we want this?
> This precludes using two address spaces with different memory protections. I understand why this assumption may be useful for optimization, but not sure we want it.
If we know the pointer is to a valid object, does different memory protection really matter? For objects living on the stack, I guess it would make a difference in failure behavior for the stack overflow case.

I don't believe address spaces should be a mechanism for you-must-get-this-memory access type of guarantee, and that's what the point of volatile is (which is why I put this exception here for volatile)


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

https://reviews.llvm.org/D63525