[PATCH] D84684: [VPlan] Use VPValue def for VPInterleaveRecipe.

[Florian Hahn via Phabricator via llvm-commits]

fhahn updated this revision to Diff 296186.
fhahn added a comment.

Thanks for taking a look. Addressed comments.

In D84684#2308806 <https://reviews.llvm.org/D84684#2308806>, @dmgreen wrote:

> Would this now be based upon D88380 <https://reviews.llvm.org/D88380> now instead?

Yep, let me update the links in Phab.

> 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.

Agreed, we could also model it so that VPInterleaveRecipe creates a single vector with all loaded values and then use extract instructions for the different parts of the interleave group. This keeps the modeling in the VPValue classes & co a bit simpler. But it has the cost that we need to add additional instructions/recipes to the plan, which need to be considered by other analyses and transformations.  Another problem is that we would have to materialize a vector with all loaded values, which is completely artificial.

I think we have the make the following trade-off. Either we add additional complexity to VPValue & co to model recipes that produce multiple VPValues or we add additional instructions/recipes to the plans we generate.

Personally I think the additional complexity in VPValue & co is worth having simpler plans. Also, there might be additional complex recipes that produce multiple values in the future, which would also benefit from dedicated multi-value support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84684

Files:
  llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
  llvm/lib/Transforms/Vectorize/VPRecipeBuilder.h
  llvm/lib/Transforms/Vectorize/VPlan.cpp
  llvm/lib/Transforms/Vectorize/VPlan.h
  llvm/test/Transforms/LoopVectorize/interleaved-accesses.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D84684.296186.patch
Type: text/x-patch
Size: 12307 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201005/d90e507c/attachment-0001.bin>