[PATCH] D128542: [LV] Allow scalable vectorization with vscale = 1

Mon Jun 27 03:00:19 PDT 2022

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

Thanks for fixing this @reames. The approach seems sensible, because `vscale` is likely to be larger than 1 so it shouldn't conservatively assume scalarisation will happen at this point in the LV. If `vscale` could be 1 at runtime and the codegen for `<vscale x 1 x eltty>` is less efficient than for (scalar) `eltty`, then the cost-model should probably reflect that. Note that you can distinguish the `vscale` value to //tune// for with `TargetTransformInfo::getVScaleForTuning()` (which is different from the vscale ranges the generated code will run on (albeit possibly inefficiently), which it gets from the `vscale_range` attribute). For Arm we've implemented this TTI function to use the information from `-mcpu`.

================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:6719-6721
+        // If we ever find a target which wants to lower scalable vectors
+        // back to scalars, we'll need to update this code to explicitly
+        // ask TTI about the register class uses for each part.
----------------
I think this comment can be removed. If this is ever the case, the LV shouldn't be using scalable vectors, but fixed-size vectors instead and leave it to the code-generator to choose the right register class and instructions. This is actually what we do for SVE when we compile for a specific vector-width; we vectorize using fixed-width vectors and map them to SVE registers instead of NEON.

================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:6725
+        TypeNotScalarized = NumParts < VF.getKnownMinValue();
+    } else {
       C = InstructionCost::getInvalid();
----------------
nit: unnecessary curly braces.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128542