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

[Gerolf Hoflehner via llvm-commits]

In this case there could be another issue coming into play. Some of the discussions centering around the IR heuristics assume but don’t check that the target is OoO. What if the core is in-order? Or is this a non-issue anymore for x86 even in the embedded space?

Overall I think Sanjay’s thought about pushing the optimization/tuning down to the MachineCombiner goes in the right direction. As a local peephole this kind of tuning always seems to end up giving mixed performance results over time. I have seen this before on Itanium and more recently on ARM64 where for some time a local patch for tuning the sFormingBranchFromSelectProfitable heuristics gave some gains on “commercial benchmarks” for a few months before they vanished again because of changes to the instruction mix.

-Gerolf

> On Feb 17, 2016, at 3:59 PM, Mitch Bodart via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> mbodart added a comment.
> 
> I'm looking into resurrecting the nonlocal dead store elimination in http://reviews.llvm.org/D13363,
> but one of the snags is a performance issue related to select-vs-branch choices.  That change enables
> more selects, which unfortunately incur a 10 to 20% perf drop on some benchmarks in the EEMBC automotive
> suite, on various X86 architectures.
> 
> One technique for recouping most of these drops is to relax the load-feeding-cmp heuristic in
> isFormingBranchFromSelectProfitable, to allow the load to have multiple users, all of which are cmp's.
> Yes, this is subject to the same "is this a reasonable heuristic at this point in compilation" questions
> as discussed in this review, and a target-specific lowering may be preferable.  But such lowering does
> not yet exist, which is perhaps why we're seeing continual tuning in this function.
> 
> Is it worth pursuing more tuning in isFormingBranchFromSelectProfitable,
> or is that likely to be rejected in favor of option 2?
> 
> regards,
> 
> - mitch
> 
> 
> http://reviews.llvm.org/D16836
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits