[PATCH] D99750: [LV, VP]VP intrinsics support for the Loop Vectorizer

[Alexey Bataev via Phabricator via llvm-commits]

ABataev added a comment.

Hi Ayal, thanks for the review.

In D99750#4588726 <https://reviews.llvm.org/D99750#4588726>, @Ayal wrote:

> Joining this review late admittedly, adding comments relative to recent version.
>
> What loops are amenable to use EVL by this patch should be clearly documented, tested, and potentially VPlanVerified:
> Innermost loops, must not be unrolled, must not use masked interleave groups, must produce tail - which must be folded.

Do you ask to ad this to the summary, right?

> What about loops processing elements of multiple/mixed sizes?
> What about reductions, fixed-order recurrences?

No restrictions for now AFAIR, but some extra work required for better results.

> What is the benefit of using EVL on top of scalable vectors - only replacing the active-lane-mask / tail-folding compare setting the header mask? Can that be done as a VPlan-to-VPlan transform?

Well, theoretically this can be considered as a kind of active-lane-mask replacement. And there are RISC-V CPUs which follow this way. But for some of them this is not quite so and it may require some extra stuff like knowledge about the active vector length on the previous iteration(s) + dynamically balance the actual vector length.
We're going to add this recipe in future (it is required for reductions, AFAIR). Can this be considered as a stopper for VPlan-to-VPlan?

> Should the title be more accurate, as it **Introduces** VP Intrinsics, or rather Introduces **EVL**? Seems also possible to first introduce VP Intrinsics while setting EVL to a maximum default, i.e., w/o actually introducing EVL, hence would be good to emphasize in the title.

No, setting EVL to default maximum won't work for loads/stores.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99750