[PATCH] D31710: [AMDGPU] Fix for issue in alloca to vector promotion pass
Matt Arsenault via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 19 10:10:40 PDT 2017
arsenm added inline comments.
================
Comment at: lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp:405-407
+ // Canonical form means that the pointer should be a GEP
+ LoadInst *LI = cast<LoadInst>(Inst);
+ return isa<GetElementPtrInst>(LI->getPointerOperand());
----------------
dstuttard wrote:
> arsenm wrote:
> > This isn't necessarily true. You could have a direct store to an alloca pointer for example
> Ok - but since the current implementation expects a gep that's what is being verified here.
> Would a comment change be sufficient?
Yes
================
Comment at: lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp:432
AllocaTy->getElementType()->isVectorTy() ||
+ AllocaTy->getElementType()->isArrayTy() ||
AllocaTy->getNumElements() > 4 ||
----------------
dstuttard wrote:
> arsenm wrote:
> > I can see how this would be a problem and not handled today, but I don't think anything flatten array types. You could still see something like [4 x [4 x i32]], though the elements will still be individually addressed, not as aggregate loads and stores
> Yes you're correct. It should be possible to extend this routine to handle (for instance) [2 x [2 x i32]] and still fit in the current size constraints.
> The current implementation won't handle this though.
> Perhaps a FIXME or TODO comment to that effect in here?
Yes
https://reviews.llvm.org/D31710
More information about the llvm-commits
mailing list