[PATCH] D130895: [RISCV] Make VL choosing for a splat-like VMV based on its users

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 28 09:52:11 PDT 2022


craig.topper added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:2548
+  // Check whether VL operands are the same. Return common non-constant VL.
+  SDValue VL = getVLOperand(*Range.begin(), TII);
+  if (all_of(drop_begin(Range),
----------------
asi-sc wrote:
> craig.topper wrote:
> > craig.topper wrote:
> > > I don't think you can assume the using instruction VL is relative to the same SEW/LMUL as the splat. There could have been a bitcast between them that changed the element size. Bitcasts don't generate code. I think insert_subvector/extract_subvector can also change the type without creating any code. Mainly for fractional LMULs.
> > You'll need to extract the SEW and LMUL from both instructions and make sure they are in the same ratio so they would have the same VLMax.
> I tried to write a test that shows the behavior our described. And I have to say it is tricky for me.
> Bitcasts preserve SEW/LMUL ratio, llvm.vector.extract intrinsic results in additional COPY at DAG to DAG stage, shufflevector instructions do not support indexes other than zeroinitializer for scalable vectors. 
> Is it in general correct if the result of VMV is used in the instruction with another SEW/LMUL ratio? It seems to me as something illegal at DAG to DAG stage.
Bitcasts don't preserve the SEW/LMUL ratio. They have a constant LMUL and change the SEW. So an LMUL=4 SEW=32 can become an LMUL=4 SEW=64.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130895



More information about the llvm-commits mailing list