[PATCH] D71760: [POC][SVE] Allow code generation for fixed length vectorised loops [Patch 1/2].

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 20 12:49:58 PST 2019


efriedma added a comment.

I've spent a little time considering alternatives.  There are basically a few possibilities here:

1. Say the types aren't legal, and convert the types as part of type legalization.
2. Say the types are legal, but the operations aren't, and custom-legalize (or teach LegalizeDAG to legalize) all the operations.
3. Say the types and patterns are legal, and add a bunch of extra patterns to match the instructions.

Any of these options have rough edges... but type legalization seems more natural to me.  That would let you rewrite all the types, so you aren't stuck with "fake" types for values that are live across basic blocks.  And it would let you take more advantage of existing type legalization infrastructure: you don't have to have a custom legalization handler for every SVE operation, and you probably get better handling of cases where the fixed->scalable transform still leaves some illegal types.  And the code would be naturally shared with other targets.

You haven't really demonstrated how you plan to handle i1 vectors, in particular, `<8 x i1>` might be `<vscale x 8 x i1>` or `<vscale x 4 x i1>` depending on how it's generated/used.  You can probably make it work with your current approach; I guess you end up inserting predicate pack/unpack operations in Select(), and we should be able to eliminate most of the redundant operations?  Not completely sure how that works out.  (If an i1 vector is live across basic blocks, the generated code gets really messy, but that's not really specific to SVE.)



================
Comment at: llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp:3139
+  case ISD::TRUNCATE: {
+    EVT InVT = Node->getOperand(0).getValueType();
+    // Only intercept combinations not handled by tablegen based isel patterns.
----------------
If we're going to use this approach, we probably want to custom legalize TRUNCATE and ANY_EXTEND, and leave only the INSERT_SUBVECTOR/EXTRACT_SUBVECTOR operations to be handled in Select().


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

https://reviews.llvm.org/D71760





More information about the llvm-commits mailing list