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

[Hal Finkel via llvm-commits]

hfinkel 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());
----------------
flyingforyou wrote:
> 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.
> 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.

This is similar to the code in `sinkSelectOperand`, but also different. In `sinkSelectOperand`, we explicitly check that the operand we've found *is* expensive. In your proposed change, we have the opposite: We know only that the operand is irrelevant to performance (to first approximation). You need to look through that operand to find the IR instruction that is relevant, and then you can make a determination (or you might find a constant, argument, etc.).

Have you looked at the TSVC case? What change is it making that matters?


http://reviews.llvm.org/D16836