[PATCH] D152828: [MachineSink][AArch64] Sink instruction copies when they can replace copy into hard register or folded into addressing mode

Dave Green via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 4 00:46:17 PDT 2023


dmgreen added a comment.

I've been wondering how to stage this, whilst trying to move towards https://reviews.llvm.org/D155470#4527270. I think this implements something closer to "Ext23Fast" from the 4 options there, but checks for LSLFast.

It might be best to go with this, and then we can adjust the Target features and clean up the uses in another patch. Otherwise we are trying to do too many things at once, and there is already quite a bit of code here. I have some questions inline about the folding of add's, but otherwise from what I can tell this looks good.



================
Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:2926
+      return false;
+    // Shift 1 (scale 2) in address is one extra cycle and one extra unit on
+    // some CPUs.
----------------
I believe it is shifts of 1 or 4 that would be more expensive for OoO cores, but the other shift types are also cheap. AddrLSLFast means any addressing mode with a LSL with shift <= 3 are cheap. ALULSLFast means adds/subs with LSL<=4 are fast.

I think the logic should be similar to that in DAGCombine (ignoring register pressure for a moment). If we are optimizing for size or there are no other uses the fold should be beneficial. Otherwise we treat it as cheap if we have AddrLSLFast and the shift is <= 3. An ADDXrs could take 2 cycles anyway so could be more aggressive?

Does this take into account the number of uses, and should it? Should it fold more under Optsize?


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

https://reviews.llvm.org/D152828



More information about the llvm-commits mailing list