[PATCH] D31924: SROA: Allow eliminating addrspacecasted allocas

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 3 11:08:05 PDT 2019


arsenm added inline comments.


================
Comment at: lib/Transforms/Scalar/SROA.cpp:1588
+    Ptr = IRB.CreatePointerBitCastOrAddrSpaceCast(Ptr, PointerTy,
+                                                  NamePrefix + "sroa_cast");
+  }
----------------
efriedma wrote:
> Why do we want to generate an address-space cast here, as opposed to performing the memory operation using the alloca's natural address-space?
You're right, this is unnecessary


================
Comment at: lib/Transforms/Scalar/SROA.cpp:1557
+    unsigned Opc = Operator::getOpcode(Ptr);
+    if (Opc == Instruction::BitCast || Opc == Instruction::AddrSpaceCast) {
       Ptr = cast<Operator>(Ptr)->getOperand(0);
----------------
sanjoy wrote:
> arsenm wrote:
> > sanjoy wrote:
> > > Are you ruling that `GEP(CAST(X), 1)` is the same as `CAST(GEP X, 1)`?  If so, I'm not sure this is correct given your constraint on address space casts.
> > > 
> > > For instance, if casting from address space N to M, with both spaces having the same pointer width, involves flipping the high and low halves of the pointer then `GEP(CAST(X), 1)` is not the same as `(CAST(GEP X, 1))`.
> > > 
> > > Of course, this means that GEPs over pointers of address space M are different operations from GEPs over pointers of address space N, but that's allowed, AFAIK.
> > > 
> > Yes, those should be the same
> Then you need to change the langref to disallow address space casts as the above (flipping the high and low halfs of the pointer).
Does this only matter because of the newly introduced addrspacecast? This may change the pointer value, but we only care about number of bytes indexed off of the original object. Changing the representation in the middle shouldn't change the total number of bytes addressed from the original object?


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

https://reviews.llvm.org/D31924





More information about the llvm-commits mailing list