r201439 - [CodeGenPrepare][AddressingModeMatcher] Give up on type promotion if the

[Tom Stellard]

Hi Quentin,

Sorry I missed this on the first time around: 

>--- a/lib/Transforms/Scalar/CodeGenPrepare.cpp
>+++ b/lib/Transforms/Scalar/CodeGenPrepare.cpp
>@@ -1728,6 +1730,35 @@
>TypePromotionHelper::promoteOperandForOther(Instruction *SExt,
>   return SExtOpnd;
> }
> 
>+/// IsPromotionProfitable - Check whether or not promoting an
>instruction
>+/// to a wider type was profitable.
>+/// \p MatchedSize gives the number of instructions that have been
>matched
>+/// in the addressing mode after the promotion was applied.
>+/// \p SizeWithPromotion gives the number of created instructions for
>+/// the promotion plus the number of instructions that have been
>+/// matched in the addressing mode before the promotion.
>+/// \p PromotedOperand is the value that has been promoted.
>+/// \return True if the promotion is profitable, false otherwise.
>+bool
>+AddressingModeMatcher::IsPromotionProfitable(unsigned MatchedSize,
>+                                             unsigned SizeWithPromotion,
>+                                             Value *PromotedOperand) const {
>+  // We folded less instructions than what we created to promote the operand.
>+  // This is not profitable.
>+  if (MatchedSize < SizeWithPromotion)
>+    return false;
>+  if (MatchedSize > SizeWithPromotion)
>+    return true;
>+  // The promotion is neutral but it may help folding the signextension in
>+  // loads for instance.
>+  // Check that we did not create an illegal instruction.
>+  Instruction *PromotedInst = dyn_cast<Instruction>(PromotedOperand);
>+  if (!PromotedInst)
>+    return false;
>+  return TLI.isOperationLegalOrCustom(PromotedInst->getOpcode(),
>+                                      EVT::getEVT(PromotedInst->getType()));

This won't work, because the IR Instructions and SelectionDAG Opcodes
have different enumeration values.  The original test case must have
passed, because it is using a default TargetLowering implementation
rather than the one from R600.

I've attached an updated version of the original test case which compiles
the program using llc and triggers the bug again.

I couldn't find other transforms that use the isOperation* callbacks, so
I think you may have to add a function to convert from IR Instruction to
SelectionDAG Opcodes or implement this some other way.

Thanks,
Tom
-------------- next part --------------
diff --git a/test/CodeGen/R600/codegen-prepare-addrmode-sext.ll b/test/CodeGen/R600/codegen-prepare-addrmode-sext.ll
index 6c8b26a..f8b4a61 100644
--- a/test/CodeGen/R600/codegen-prepare-addrmode-sext.ll
+++ b/test/CodeGen/R600/codegen-prepare-addrmode-sext.ll
@@ -1,11 +1,14 @@
-; RUN: opt -codegenprepare -S -o - %s | FileCheck %s
+; RUN: opt -codegenprepare -S -o - %s | FileCheck --check-prefix=OPT --check-prefix=FUNC %s
+; RUN: llc < %s -march=r600 -mcpu=verde -verify-machineinstrs | FileCheck --check-prefix=SI-LLC --check-prefix=FUNC %s
 
 target datalayout = "e-p:32:32-p1:64:64-p2:64:64-p3:32:32-p4:32:32-p5:64:64-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64"
 target triple = "r600--"
 
-; CHECK-LABEL: @test
-; CHECK: mul
-; CHECK-NEXT: sext
+; FUNC-LABEL: @test
+; OPT: mul nsw i32
+; OPT-NEXT: sext
+; SI-LLC: V_MUL_LO_I32
+; SI-LLC-NOT: V_MUL_HI
 define void @test(i8 addrspace(1)* nocapture readonly %in, i32 %a, i8 %b) {
 entry:
   %0 = mul nsw i32 %a, 3