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

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 19 07:27:31 PDT 2019


arsenm marked 3 inline comments as done.
arsenm added inline comments.


================
Comment at: docs/LangRef.rst:9694
+space conversion is legal then both result and operand refer to the
+same memory location. The conversion must have no side effects, or
+capture the value of the pointer.
----------------
theraven wrote:
> What does 'is legal' actually mean?  For example, if I have a 32-bit VA space and a 64-bit VA space in the same process with a subset of the program understanding only one and a shim layer understanding both, then the cast from 32-bit to 64-bit will always succeed but the converse cast is always a statically valid operation but may dynamically fail (and the failure case may be to return null).
I was thinking legal means a dereferencable result. If you were to access the result when the cast failed, it would be undefined


================
Comment at: docs/LangRef.rst:9695
+same memory location. The conversion must have no side effects, or
+capture the value of the pointer.
+
----------------
theraven wrote:
> Does this not preclude using address space casts to make pointers visible to GC (or, conversely, to notify the GC that a pointer has escaped)?  I think we may need to define what 'capture' means in this context.  I believe the goal of this is to state that the compiler is free to elide address space casts with no uses?
I'm trying to reiterate that this is not an operation that touches memory in any way. We do allow addrspacecasts in constant expressions, and they can't trap. Elision should be OK.

The intent is addrspacecast has stronger aliasing properties than a ptrtoint/inttoptr pair, which was part of the original intent of adding a new instruction.


================
Comment at: docs/LangRef.rst:9704
+the result back to the original address space should yield the
+original bit pattern).
 
----------------
theraven wrote:
> I believe that this holds only if both address spaces are permutations.  Again, the simple 32/64-bit case, a round trip starting in the 32-bit world is always possible, but the converse does not apply.
This probably needs an additional constraint that the result was also dereferencable / legal as stated before. The goal is it should be legal to insert new addrspacecasts back to the source addrspace in certain contexts. The interesting ones are cases where you are dereferencing the pointer anyway, so it would have been undefined if the cast failed


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

https://reviews.llvm.org/D63525





More information about the llvm-commits mailing list