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

David Chisnall via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 19 01:22:46 PDT 2019


theraven added a comment.

Thanks for working on this, it's a seriously underspecified part of LLVM.



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


================
Comment at: docs/LangRef.rst:9695
+same memory location. The conversion must have no side effects, or
+capture the value of the pointer.
+
----------------
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?


================
Comment at: docs/LangRef.rst:9704
+the result back to the original address space should yield the
+original bit pattern).
 
----------------
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.


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

https://reviews.llvm.org/D63525





More information about the llvm-commits mailing list