[PATCH] D143722: [RISCV][NFC] Add test for different LMULs in vectorizer

[Philip Reames via Phabricator via llvm-commits]

reames accepted this revision.
reames added a comment.
This revision is now accepted and ready to land.

LGTM w/comment addressed.



================
Comment at: llvm/test/Transforms/LoopVectorize/RISCV/lmul.ll:2
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt < %s -passes=loop-vectorize -mtriple riscv64 -mattr=+v -S | FileCheck %s -check-prefix=DEFAULT
+; RUN: opt < %s -passes=loop-vectorize -mtriple riscv64 -mattr=+v -S --riscv-v-register-bit-width-lmul=1 | FileCheck %s -check-prefix=LMUL1
----------------
I think this would be more clear to drop the DEFAULT and simply have the default configuration use an LMUL1 check line.  Then when we switch the default, we simply change that to LMUL2.  


================
Comment at: llvm/test/Transforms/LoopVectorize/RISCV/lmul.ll:116
+; LMUL2-NEXT:    [[TMP15:%.*]] = getelementptr inbounds i64, ptr [[TMP10]], i64 [[TMP14]]
+; LMUL2-NEXT:    [[WIDE_LOAD1:%.*]] = load <vscale x 2 x i64>, ptr [[TMP15]], align 4
+; LMUL2-NEXT:    [[TMP16:%.*]] = add <vscale x 2 x i64> [[WIDE_LOAD]], shufflevector (<vscale x 2 x i64> insertelement (<vscale x 2 x i64> poison, i64 1, i64 0), <vscale x 2 x i64> poison, <vscale x 2 x i32> zeroinitializer)
----------------
Ok, there's something surprising going on here.  When we go from LMUL1 to LMUL2, we appear to be *both* doubling the vector length (expected), and doing additional unrolling (unexpected).  This means that the effective VF of the loop increases not by 2, but by 4.  

I think we need to figure out what's causing the unrolling and isolate that.  We should be changing one thing at a time here, not two.  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143722