[llvm] [X86] Remove redundant TEST after shifts when count is non-zero (PR #169069)

[via llvm-commits]

================
@@ -23625,6 +23625,60 @@ static SDValue EmitTest(SDValue Op, X86::CondCode X86CC, const SDLoc &dl,
     return DAG.getNode(X86ISD::SUB, dl, VTs, Op->getOperand(0),
                        Op->getOperand(1)).getValue(1);
   }
+  case ISD::SHL:
+  case ISD::SRL:
+  case ISD::SRA: {
+    SDValue Amt = ArithOp.getOperand(1);
+
+    // Skip Constants
+    if (isa<ConstantSDNode>(Amt))
+      break;
+
+    // If optimising for size and can guarantee the shift amt is never zero
+    // the test.
+    bool OptForSize = DAG.getMachineFunction().getFunction().hasOptSize();
+
+    if (!OptForSize)
----------------
GrumpyPigSkin wrote:

I have two sets other CPUs I can test, a Core 2 Duo and a Skylake CPU, testing on the Skylake shows no issue:
Skylake:
```
Run on (4 X 1896 MHz CPU s)
-----------------------------------------------------
Benchmark           Time             CPU   Iterations
-----------------------------------------------------
BM_TEST          3.02 ns         2.70 ns    258855316
BM_NO_TEST       2.41 ns         2.16 ns    323624088
```

The Core 2 is a pretty severe case of the flag stall issue:
```
Run on (2 X 1197 MHz CPU s)
-----------------------------------------------------
Benchmark           Time             CPU   Iterations
-----------------------------------------------------
BM_TEST          5.86 ns         5.86 ns    119326116
BM_NO_TEST       13.4 ns         13.4 ns     52237503
```

On a laptop of mine 13th gen:
```
Run on (2 X 1197 MHz CPU s)
-----------------------------------------------------
Benchmark           Time             CPU   Iterations
-----------------------------------------------------
BM_TEST         0.847 ns        0.847 ns    807090405
BM_NO_TEST      0.623 ns        0.623 ns   1141524588
```
I don't have a Zen architecture here but I can get access to one so might run the same test on them later.
It seems like it could be beneficial on newer architectures at least on intel. 
uops.info does look bad in some cases for zen2-4, but I guess they are designed to show the very worse case right? They all seem to be code that likely would never get written.
 

https://github.com/llvm/llvm-project/pull/169069