[PATCH] D128427: [LoongArch] Add codegen support for load/store operations

Xi Ruoyao via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jul 2 18:42:41 PDT 2022


xry111 added inline comments.


================
Comment at: llvm/test/CodeGen/LoongArch/ir-instruction/load-store.ll:329
+; LA64-NEXT:    lu12i.w $a1, -136485
+; LA64-NEXT:    ori $a1, $a1, 3823
+; LA64-NEXT:    lu32i.d $a1, -147729
----------------
xry111 wrote:
> xen0n wrote:
> > SixWeining wrote:
> > > xry111 wrote:
> > > > Based on the previous discussion, should we move "ori" to the last instruction in the long immediate load sequence and change it to "addi.d" if possible, so a peephole optimization would be able to combine "addi.d" and "ld" into one instruction?
> > > In terms of principle this can be implemented. But seems that this is only suitable for very few scenarios (maybe only when accessing a constant memory address). I'm not very sure.
> > I think this depends on the micro-architecture. If `lu12i.w; ori; lu32i.d; lu52i.d` sequences or variations of it are macro-op-fusioned, then breaking away from the current pattern could instead harm performance. OTOH it could be a net benefit but as @SixWeining pointed out this case of accessing absolute addresses is probably too rare to justify a special-case.
> Then I'll withdraw the proposal, at least for now.
I tested some very simple cases on a 3A5000LL.  It seems you can move `ori` after `lu32i.d` or `lu52i.d`, or change it to `addi.d` or even `xori` w/o performance loss.  Maybe my case is too noob and can't reflect the performance of real apps though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128427



More information about the llvm-commits mailing list