[AlignmentFromAssumptions] Fix a SCEV assertion resulting from address space differences.

Summary:
On targets with different pointer sizes, -alignment-from-assumptions could attempt to create SCEV expressions which use different effective SCEV types. The provided test illustrates the issue.

In `getNewAlignment`, AASCEV would be the (only) alloca, which would have an effective SCEV type of i32. But PtrSCEV, the GEP in this case, due to being in the flat/default address space, will have an effective SCEV of i64.

This patch resolves the issue by truncating PtrSCEV to AASCEV's effective type.

Reviewers: hfinkel, jdoerfert

Reviewed By: jdoerfert

Subscribers: jvesely, nhaehnle, hiraditya, javed.absar, kerbowa, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75471

Author: DiamondLovesYou

llvm/lib/Transforms/Scalar/AlignmentFromAssumptions.cpp

@@ -127,6 +127,11 @@ static unsigned getNewAlignment(const SCEV *AASCEV, const SCEV *AlignSCEV,
                                 const SCEV *OffSCEV, Value *Ptr,
                                 ScalarEvolution *SE) {
   const SCEV *PtrSCEV = SE->getSCEV(Ptr);
+  // On a platform with 32-bit allocas, but 64-bit flat/global pointer sizes
+  // (*cough* AMDGPU), the effective SCEV type of AASCEV and PtrSCEV
+  // may disagree. Trunc/extend so they agree.
+  PtrSCEV = SE->getTruncateOrZeroExtend(
+      PtrSCEV, SE->getEffectiveSCEVType(AASCEV->getType()));
   const SCEV *DiffSCEV = SE->getMinusSCEV(PtrSCEV, AASCEV);
 
   // On 32-bit platforms, DiffSCEV might now have type i32 -- we've always

llvm/test/Transforms/AlignmentFromAssumptions/amdgpu-crash.ll

@@ -0,0 +1,33 @@
+; Test that we don't crash.
+; RUN: opt < %s -alignment-from-assumptions -S
+; RUN: opt < %s -passes=alignment-from-assumptions -S
+
+target datalayout = "e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-ni:7"
+
+%"core::str::CharIndices.29.66.90.114.138.149.165.173.181.197.205.213.229.387.398" = type { [0 x i64], i64, [0 x i64], { i8*, i8* }, [0 x i64] }
+%"unwind::libunwind::_Unwind_Exception.9.51.75.99.123.147.163.171.179.195.203.211.227.385.396" = type { [0 x i64], i64, [0 x i64], void (i32, %"unwind::libunwind::_Unwind_Exception.9.51.75.99.123.147.163.171.179.195.203.211.227.385.396"*)*, [0 x i64], [6 x i64], [0 x i64] }
+%"unwind::libunwind::_Unwind_Context.10.52.76.100.124.148.164.172.180.196.204.212.228.386.397" = type { [0 x i8] }
+
+define void @"_ZN44_$LT$$RF$T$u20$as$u20$core..fmt..Display$GT$3fmt17h7b1d039c7ff5e1feE"() {
+start:
+  %_15.i.i = alloca %"core::str::CharIndices.29.66.90.114.138.149.165.173.181.197.205.213.229.387.398", align 8, addrspace(5)
+  br label %bb12.i.i
+
+bb12.i.i:                                         ; preds = %start
+  %0 = addrspacecast %"core::str::CharIndices.29.66.90.114.138.149.165.173.181.197.205.213.229.387.398" addrspace(5)* %_15.i.i to %"core::str::CharIndices.29.66.90.114.138.149.165.173.181.197.205.213.229.387.398"*
+  %ptrint53.i.i = ptrtoint %"core::str::CharIndices.29.66.90.114.138.149.165.173.181.197.205.213.229.387.398"* %0 to i64
+  %maskedptr54.i.i = and i64 %ptrint53.i.i, 7
+  %maskcond55.i.i = icmp eq i64 %maskedptr54.i.i, 0
+  call void @llvm.assume(i1 %maskcond55.i.i)
+  br i1 undef, label %bb20.i.i, label %bb3.i.i.i.i.i.preheader.i.i
+
+bb3.i.i.i.i.i.preheader.i.i:                      ; preds = %bb12.i.i
+  %1 = getelementptr inbounds %"core::str::CharIndices.29.66.90.114.138.149.165.173.181.197.205.213.229.387.398", %"core::str::CharIndices.29.66.90.114.138.149.165.173.181.197.205.213.229.387.398"* %0, i64 0, i32 0, i64 0
+  store i64 0, i64* %1, align 8
+  unreachable
+
+bb20.i.i:                                         ; preds = %bb12.i.i
+  ret void
+}
+
+declare void @llvm.assume(i1)