[PATCH] D31924: SROA: Allow eliminating addrspacecasted allocas

David Chisnall via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 21 01:11:08 PDT 2017


theraven added inline comments.


================
Comment at: docs/LangRef.rst:8460
+same memory location. The pointer conversion cannot be an arbitrarily
+complex value modification. For a defined result, the inverse cast to
+the original address space should yield the original pointer value.
----------------
efriedma wrote:
> arsenm wrote:
> > efriedma wrote:
> > > "The pointer conversion cannot be an arbitrarily complex value modification." is a bit vague... it'd be better if we could specifically say what transforms are allowed.
> > Would just dropping that sentence work? The intent is more clear in the second sentence where it needs to be reversible
> Yes, I think that's fine.
It would be nice to clarify what 'legal' means in this context.  For us, the relationship between address spaces 0 and 200 rely on some run-time properties.  Address space 200 is always a superset of address space 0, so it is always safe to cast from AS 0 to AS 200, but the converse might not be possible and will give either a valid value (without bounds information) or a null pointer.  A cast from AS200 -> AS0 -> AS200 may result in a null pointer if the address is outside the range covered by AS0.  The same would apply on microcontrollers with a 32-bit global address space and a 16-bit address space mapped within that: you could always cast from the 16-bit range to the 32-bit range and back, but casting from an arbitrary 32-bit range to the 16-bit range and back may not work.


================
Comment at: lib/Analysis/PtrUseVisitor.cpp:34
 
-  return GEPI.accumulateConstantOffset(DL, Offset);
+  APInt TmpOffset(DL.getPointerTypeSizeInBits(GEPI.getType()), 0);
+  if (GEPI.accumulateConstantOffset(DL, TmpOffset)) {
----------------
No changes suggested here, but in our version we have queries on the data layout that differentiate between the type and the range of a pointer (ours are 128- or 256-bit sized, but with a 64-bit range).


https://reviews.llvm.org/D31924





More information about the llvm-commits mailing list