[PATCH] D121371: [AMDGPUPromoteAlloca] Make compatible with opaque pointers

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 10 07:23:52 PST 2022


nikic added inline comments.


================
Comment at: llvm/lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp:433
+      // This is a store of the pointer, not to the pointer.
+      if (U->get() != Ptr)
         return false;
----------------
arsenm wrote:
> Doesn't this need to check the exact operand number in case a pointer is being stored to itself?
Yeah, at least far as intent goes. I don't think it's really relevant for correctness, but possibly for profitability.


================
Comment at: llvm/test/CodeGen/AMDGPU/promote-alloca-array-aggregate.ll:40
 ;
   %i = alloca i32
   %f1 = alloca [1 x float]
----------------
arsenm wrote:
> Weird this test isn't using the right address space
Yeah, though I don't think it really matters for the transform. Should I adjust the test to use addrspace(5) for the allocas?


================
Comment at: llvm/test/CodeGen/AMDGPU/promote-alloca-array-aggregate.ll:75-78
+; CHECK-NEXT:    [[TMP1:%.*]] = bitcast [2 x float]* [[F1]] to <2 x float>*
+; CHECK-NEXT:    [[TMP2:%.*]] = load <2 x float>, <2 x float>* [[TMP1]], align 8
+; CHECK-NEXT:    [[TMP3:%.*]] = insertelement <2 x float> [[TMP2]], float [[FOO3]], i32 0
+; CHECK-NEXT:    store <2 x float> [[TMP3]], <2 x float>* [[TMP1]], align 8
----------------
arsenm wrote:
> I'm not sure what's going on here, but it may be an artifact of the test using the wrong address space for the stack
This is an intended change: `bitcast` should get the same treatment as `gep p, 0, 0`. This transform generally relies on SROA and InstCombine to clean up the mess afterwards.


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

https://reviews.llvm.org/D121371



More information about the llvm-commits mailing list