[PATCH] D153351: [RISCV] Fold vmv.v.v into vops

Luke Lau via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 10 09:02:11 PDT 2023


luke added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:3517
+
+    // Make sure there's a corresponding MaskedPseudo otherwise it's not safe to
+    // change VL.
----------------
reames wrote:
> reames wrote:
> > Please rebase this over D154620, and then use the exact same code structure as the vmerge transform.  Having them different makes it very hard to follow.  
> > 
> > Hm, this is just a thought.  But could we take the existing vmerge transform, and split it into two steps?  If a vmv.v.v is like a vmerge with a all ones mask, could the vmerge transform become "first form vmv.v.v" and "then fold vmv.v.v into true"?  We in fact already have both of these pieces, can we simply reorder and restructure?
> Ignore the just a thought bit.  That handles the sub-case where the mask is all ones, but does not handle the arbitrary mask case.  I got myself confused with thinking about the unmasking peephole, but that's a different bit of logic.
Yeah, I don't think we can express all vmv.v.v as vmerges but I took another look at the specification and noticed this note in 11.16:

> The vector integer move instructions share the encoding with the vector merge instructions, but with vm=1 and vs2=v0.

So a vmv.v.v isn't just like vmerge with an all ones mask, it literally is one (without a mask). I presume we can then generalise the existing vmerge fold to handle vmv.v.v, so I'll give that a try first


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153351



More information about the llvm-commits mailing list