[PATCH] D16836: [CodeGenPrepare] Don't transform select instructions into branches when both of operands are cheap

[Junmo Park via llvm-commits]

flyingforyou added inline comments.

================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:4479
@@ +4478,3 @@
+  // If both operand of the select is expected to fold away in lowering,
+  // the mispredicted branch might be more painful.
+  auto *TI = dyn_cast<Instruction>(SI->getTrueValue());
----------------
hfinkel wrote:
> I don't understand what's going on here. So what if they fold away? They could be bitcasts, or free extensions/truncations, etc. Wouldn't you need to recurse up the use/def chain to find the non-free operand and making some determination based on that?
Thanks Hal.

This checking is simillar with sinkSelectOperand.

```
  // If either operand of the select is expensive and only needed on one side
  // of the select, we should form a branch.
  if (sinkSelectOperand(TTI, SI->getTrueValue()) ||
      sinkSelectOperand(TTI, SI->getFalseValue()))
    return true;
}

/// Check if V (an operand of a select instruction) is an expensive instruction
/// that is only used once.
static bool sinkSelectOperand(const TargetTransformInfo *TTI, Value *V) {
  auto *I = dyn_cast<Instruction>(V);
  // If it's safe to speculatively execute, then it should not have side
  // effects; therefore, it's safe to sink and possibly *not* execute.
  return I && I->hasOneUse() && isSafeToSpeculativelyExecute(I) &&
         TTI->getUserCost(I) >= TargetTransformInfo::TCC_Expensive;
}
```

What I want to do is if the Instruction is expected to fold away or it is chep, we don't transform conditional select to branch.

The main reason of transforming select to branch is hiding execution cycles of expensive instruction likes division. 
For example, division would be taken more than 19~32 cycles for execution (on Cortex-A57). But If banch prediction is almost correct and we don't choice result of division, we can hide extra cycles of division.

`isFormingBranchFromSelectProfitable` is consist of heuristic checkings.

I don't think we need to recurse up the use/def chain to find non-free operand. We can expect that free extension/truncations might not relate with expensive instructions like division. And If we should apply checking use/def chain, we may need to change `sinkSelectOperand` function also.


http://reviews.llvm.org/D16836