[PATCH] D84684: [VPlan] Use VPValue def for VPInterleaveRecipe.
Dave Green via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Oct 2 09:09:13 PDT 2020
dmgreen added a comment.
Would this now be based upon D88380 <https://reviews.llvm.org/D88380> now instead?
I was thinking about interleaving a little. Trying some experiments to do with "de-interleaving" code. (Much like the VPlanSLP stuff I think).
The LLVM-IR equivalent of this would be an extract from a struct? Would it be worth representing this in a similar way? There could be a VPInterleaveRecipe which was a VPValue, with multiple "VPExtractElementRecipe"'s or something similar. Those would have 1 operand - the VPInterleaveRecipe and act as the "real" VPValues. They could have a 0 cost and possible hold the index for which element they are getting out of the interleaving group. Maybe there would be a validate method to make sure they remain as the only users of a VPInterleaveRecipe.
It is essentially equivalent to these other ways of handling it as a new type of VPValue, but isn't as tied into the lower levels of the class. What do you think? There might be something about it that wouldn't work, but it might be a simple way to handle these multiple-result nodes.
================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7328
+ unsigned j = 0;
+ for (unsigned i = 0; i < IG->getFactor(); i++)
+ if (Instruction *Member = IG->getMember(i)) {
----------------
Should this be surrounded by some sort of "if it's a load IG" check?
Equally, do we need to be adding the operands for a store IG group?
================
Comment at: llvm/lib/Transforms/Vectorize/VPlan.h:1065
+/*template <> struct simplify_type<VPMultiValue> {*/
+// using SimpleType = VPValue *;
----------------
This looks left over from something.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D84684/new/
https://reviews.llvm.org/D84684
More information about the llvm-commits
mailing list