[PATCH] D130895: [RISCV] Make VL choosing for a splat-like VMV based on its users

[Anton Sidorenko via Phabricator via llvm-commits]

asi-sc added a comment.

In D130895#3787035 <https://reviews.llvm.org/D130895#3787035>, @reames wrote:

> I've looked at a few ideas in this area, and there's an interaction I want to point out that I don't have a good answer for.
>
> While reducing the VL of a splat to match the demanded lanes can remove vsetv toggles, it can also add them.  Specifically, if the splat happens to be scheduled in a region which uses the original wider VL, then reducing the VL actually pessimizes the code.  This actually shows up in mixed VL code, particularly when combined with LICM for splats which can't be folded (profitably) into their users.
>
> We can patch part of this by extending InsertVSETVLI to allow increasing VL on splats if the splat is TA.  However, there's still a scheduling interaction here which is a bit hard to account for.
>
> I generally do believe that having VL reduction for all computation (not just splats) is generally a good idea; I'm just trying to figure out how to slice the pieces so that we can get there incrementally without nasty regressions along the way.

@reames, thanks for raising such an important question here. This change only works on splats with TA policy. So, we shouldn't get any regression for TU splats. At the same time combining this patch with modification of InsertVSETVLI you suggested should give only positive effect from my point of view:

1. at DAG to DAG stage minimal VL for vector move is chosen;
2. After modification of InsertVSETVLI we can skip unnecessary vsetv instructions for TA vector moves.

Such order of vector move transformations seems to me pretty reasonable. Let me know if you want me to look into InsertVSETVLI.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130895