[PATCH] D52570: [X86] Don't generate BMI BEXTR from X86DAGToDAGISel::matchBEXTRFromAnd

[Craig Topper via Phabricator via llvm-commits]

craig.topper created this revision.
craig.topper added reviewers: RKSimon, spatel, lebedev.ri, andreadb.

This function turns (X >> C1) & C2 into a BMI BEXTR or TBM BEXTRI instruction. For BMI BEXTR we have to materialize an immediate into a register to feed to the BEXTR instruction.

The BMI BEXTR instruction is 2 uops on Intel CPUs. It looks like on SKL its one port 0/6 uop and one port 1/5 uop. Despite what Agner's tables say. I know one of the uops is a regular shift uop so it would have to go through the port 0/6 shifter unit. So that's the same or worse execution wise than the shift+and which is one 0/6 uop and one 0/1/5/6 uop. The move immediate into register is an additional 0/1/5/6 uop.

I applied this patch and got gains on our internal benchmark suite. There were a couple regressions, but more gains.

This transform might still make sense on AMD CPUs, but I'm not sure. If may also might make sense if we can fold a load or if the and immediate is larger than 32-bits and can't be encoded as a sign extended 32-bit value or if LICM or CSE can hoist the move immediate and share it. But we'd need to look more carefully at that. In the regression I looked at it doesn't look load folding or large immediates were occurring so the regression isn't caused by the loss of those. So we could try to be smarter here if we find a compelling case.

@rksimon, @andreadb maybe you can check this on AMD CPUs?


https://reviews.llvm.org/D52570

Files:
  lib/Target/X86/X86ISelDAGToDAG.cpp
  test/CodeGen/X86/bmi-x86_64.ll
  test/CodeGen/X86/bmi.ll
  test/CodeGen/X86/extract-bits.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D52570.167180.patch
Type: text/x-patch
Size: 6147 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180926/ff3a4eea/attachment.bin>