[PATCH] D76055: [SystemZ] Improve foldMemoryOperandImpl().

Jonas Paulsson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 13 08:01:23 PDT 2020


jonpa updated this revision to Diff 250206.
jonpa added a comment.

>   logical compares (CLFHSI, CLGHSI) -- those should be trivial to add

Patch updated to include these as well, with a check for an uint<16> immediate. This gives +1800 CLGHSI and +200 CLFHSI compared to before.

>   addition (ASI, AGSI, potentially also ALSI, ALGSI) -- it should be possible to add them, I think (it may be a bit different since it would replace a read-modify-write)

These are already mostly handled, right? Exception is AHIMuxK which I couldn't commit since it is causing a test case to get a lot of uncoalesced COPYs as reported on Bugzilla. AGHIK could also be handled the same way.

> Then there are a number of instructions that operate on a byte or halfword level in memory:

The only thing I can see is just a few cases of:
NIFMux -> NI (just a few cases with "small" immediate)
OILMux -> OI few cases with small immediate
XIFMux -> XI 10 cases with small immediate

Given it is rare it seems it can probably wait..

What remains (from looking at benchmarks) seems to be:

- We can inspect the allocated physregs in foldMemoryOperandImpl(), so we could try to handle W... FP instructions. We could experiment with doing this only if there is a present allocation that fits, or what happens if we constrain it in case it is unallocated (to FP registers 0-15):

  WFA[SDX]B op 1/2 -> two address A[DEX]BR if low16 vecregs -> A[DEX]B if dst same...
  WFS[SDX]B                       S[DEX]BR                  -> S[DEX]B 
  WFC[SDX]B        ->             C[EDX]BR                  -> C[EDX]B
  WFD[SD]B         ->             D[SD]BR                   -> D[SD]B
  WFMA[SD]B        ->             MA[ED]BR                  -> MA[ED]B
  WFMS[SD]B        ->             MS[ED]BR                  -> MS[ED]B
  WFM[SD]B         ->             M[ED]BR                   -> M[EE/D]B



- MS(G)RKC -> MS(G) reg/mem mapping seems missing (4000 potential cases)
- VLVGP (Ops 1, 2)  (justa a dozen cases)  -> 2 x VLEG
- VLVGP32 (Ops 1, 2 same reg) (just ~20 cases) -> VLREPF ?
- LFER / LEFR (88 cases)

- When where 'Ops.size() == 2', for ops [0, 1]: A(G)RK, S(G)RK, NRK, ORK, WF[AS][DS]B, MS(G)RKC

Many of these have the same virt reg in operands 0 and 1, but not all.
Since we now don't use a reg/mem instruction, we do
<tmp> = reload
<tmp> = ARK  <tmp>
store <tmp>

If we could use a temporary register in foldMemoryOperandImpl(), I think we instead could do
<tmp> = A
store <tmp>

Not sure if that's allowed...


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

https://reviews.llvm.org/D76055

Files:
  llvm/lib/Target/SystemZ/SystemZInstrInfo.cpp
  llvm/test/CodeGen/SystemZ/foldmemop-imm-01.ll
  llvm/test/CodeGen/SystemZ/foldmemop-imm-02.mir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D76055.250206.patch
Type: text/x-patch
Size: 15404 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200313/7f6957a9/attachment.bin>


More information about the llvm-commits mailing list