[PATCH] D77850: [PowerPC] Exploit rldimi for ori with large immediates

Nemanja Ivanovic via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 10 05:21:28 PDT 2020


nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

This is a good idea, thanks for working on it. Just needs a slight tweak.



================
Comment at: llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:4552
+  // We won't get fewer instructions if the immediate is 32-bit integer.
+  // rldimi requires the immediate to have sequent ones with both sides zero.
+  if (!isInt64Immediate(N->getOperand(1).getNode(), Imm64) ||
----------------
s/sequent/consecutive
(in other places as well)


================
Comment at: llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:4556
+    return false;
+
+  unsigned SH = 63 - ME;
----------------
There are probably some more conditions under which you don't want to do this. What comes to mind is checking for a single use of the input to the OR (since `rldimi` is destructive) and that the output is not used in a SETCC to compare against zero.

Here's a test case:
```
long test(long a, long b) {
  return ((a | 4294967296L) > 0) ? a : b;
}
```
Prior to this patch, the codegen is:
```
        li 5, 1
        sldi 5, 5, 32
        or. 5, 3, 5
        isel 3, 3, 4, 1
```
With this patch, the codegen is:
```
        li 5, -1
        mr 6, 3
        rldimi. 6, 5, 32, 31
        isel 3, 3, 4, 1
```

At first glance, the new codegen looks no worse. However it is worse for two reasons:
1. Increased register pressure to move the value due to `rldimi` being destructive
2. Record-form rotate instead of record-form `or` is worse because the former is a two-way cracked instruction.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77850/new/

https://reviews.llvm.org/D77850





More information about the llvm-commits mailing list