[TTI] Treat AND/OR with widenable conditions as free of cost

[mkazantsev]

Summary

Because widenable conditions with eventually lower into a constant, such instructions
as and, or etc. will also be optimized away. Treat them as free.

This is an important thing to have if we want that guards represented as experimental.guard
calls and in their explicit form (branch by and with widenable condition) have the same cost
for unroller and other passes like this.

[nikic]

LG

llvm/include/llvm/Analysis/TargetTransformInfoImpl.h

526

TCC_Free?

[mkazantsev]

llvm/include/llvm/Analysis/TargetTransformInfoImpl.h

526

Yup, thanks.

llvm/include/llvm/Analysis/TargetTransformInfoImpl.h

public:
 
   unsigned getMaxInterleaveFactor(ElementCount VF) const { return 1; }
 
   InstructionCost getArithmeticInstrCost(
       unsigned Opcode, Type *Ty, TTI::TargetCostKind CostKind,
       TTI::OperandValueInfo Opd1Info, TTI::OperandValueInfo Opd2Info,
       ArrayRef<const Value *> Args,
       const Instruction *CxtI = nullptr) const {
+    // Widenable conditions will eventually lower into constants, so some
+    // operations with them will be trivially optimized away.
+    auto IsWidenableCondition = [](const Value *V) {
+      if (auto *II = dyn_cast<IntrinsicInst>(V))
+        if (II->getIntrinsicID() == Intrinsic::experimental_widenable_condition)
+          return true;
+      return false;
+    };
     // FIXME: A number of transformation tests seem to require these values
     // which seems a little odd for how arbitary there are.
     switch (Opcode) {
     default:
       break;
     case Instruction::FDiv:
     case Instruction::FRem:
     case Instruction::SDiv:
     case Instruction::SRem:
     case Instruction::UDiv:
     case Instruction::URem:
       // FIXME: Unlikely to be true for CodeSize.
       return TTI::TCC_Expensive;
+    case Instruction::And:
+    case Instruction::Or:
+      if (any_of(Args, IsWidenableCondition))
+        return TTI::TCC_Free;
+      break;
     }
 
     // Assume a 3cy latency for fp arithmetic ops.
     if (CostKind == TTI::TCK_Latency)
       if (Ty->getScalarType()->isFloatingPointTy())
         return 3;
 
     return 1;

llvm/test/Transforms/LoopUnroll/guard-cost-for-unrolling.ll

 ; RUN: opt -S -disable-output -unroll-partial-threshold=16 -debug-only=loop-unroll -passes='loop-unroll<runtime>' < %s 2>&1 | FileCheck %s
 
 ; REQUIRES: asserts
 
-; FIXME: This test is needed to make sure that the guard cost remains the same,
+; This test is needed to make sure that the guard cost remains the same,
 ; independently on guard representation form (either intrinsic call or branch with
 ; widenable condition).
 
 define void @test_guard_as_intrinsic(ptr %arr, i64 %n, i64 %bound) {
 ; CHECK-LABEL: Loop Unroll: F[test_guard_as_intrinsic] Loop %loop
 ; CHECK-NEXT:    Loop Size = 8
 ; CHECK-NEXT:    runtime unrolling with count: 2
 entry:
loop:
   br i1 %loop_cond, label %loop, label %exit
 
 exit:
   ret void
 }
 
 define void @test_guard_as_branch(ptr %arr, i64 %n, i64 %bound) {
 ; CHECK-LABEL: Loop Unroll: F[test_guard_as_branch] Loop %loop
-; CHECK-NEXT:    Loop Size = 9
+; CHECK-NEXT:    Loop Size = 8
 ; CHECK-NEXT:    runtime unrolling with count: 2
 entry:
   br label %loop
 
 loop:                                             ; preds = %guarded, %entry
   %iv = phi i64 [ 0, %entry ], [ %iv.next, %guarded ]
   %gep = getelementptr i64, ptr %arr, i64 %iv
   %bound_check = icmp ult i64 %iv, %bound