[llvm] [DAG] ComputeKnownBits - set low bit to zero for ADD(X, X) (PR #186461)

[Xinlong Chen via llvm-commits]

================
@@ -168,11 +168,12 @@ define <2 x i64> @testDoubleword(<2 x i64> %a, i64 %b, i64 %idx) {
 ; CHECK-32-NEXT:    add 5, 6, 6
 ; CHECK-32-NEXT:    addi 7, 1, -32
 ; CHECK-32-NEXT:    stxv 34, -32(1)
-; CHECK-32-NEXT:    rlwinm 6, 5, 2, 28, 29
+; CHECK-32-NEXT:    rlwinm 6, 5, 2, 28, 28
 ; CHECK-32-NEXT:    stwx 3, 7, 6
-; CHECK-32-NEXT:    addi 3, 5, 1
-; CHECK-32-NEXT:    addi 5, 1, -16
+; CHECK-32-NEXT:    li 3, 1
----------------
Xinlong-Chen wrote:

hi, simon~ thanks for helping! 

I just tried applying your [patch](https://patch-diff.githubusercontent.com/raw/llvm/llvm-project/pull/187326.patch) on my branch, but unfortunately it doesn't seem to address this regression — the compiler still generates `li + rlwimi` instead of a single `ori`.

I traced the issue to `tryBitfieldInsert` in PowerPC's ISel (`PPCISelDAGToDAG.cpp`):

```
  case ISD::OR: {
    if (N->getValueType(0) == MVT::i32)
      if (tryBitfieldInsert(N))
        return;
    // ......
```

When one operand of the `OR` is a constant, `tryBitfieldInsert` emits `RLWIMI` which needs an extra `li` to materialize the constant (2 instructions), while tablegen patterns can handle it with a single `ori`/`oris`.

A simple fix would be to bail out early in `tryBitfieldInsert` when either operand is a `ConstantSDNode`, letting the existing `ORI`/`ORIS` patterns handle it. (my commit: https://github.com/Xinlong-Chen/llvm-project/commit/c4ce2ffa3a4e5c45d664bf89ddb190dda58b527d)

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