Add tests

Re-generate machine-combiner-mir.ll test checks

We have to revert it because tests were not correctly updated by 'update_mir_test_checks.py' script. Fix in D136170. I'll regenerate tests and update the review soon.

Rebase to fetch precommitted tests

Rebase after D135776

Addressed review comments

Thanks for the review.
@dmgreen, could you please submit the patch on my behalf? Author: Anton Sidorenko <anton.sidorenko@syntacore.com>

A gentle ping.

Move FRM operands creation from setSpecialOperandAttr to finalizeInsInstrs

Make flags intersection for new instructions, add Nsz flag check.

Small code refactoring and tests update (change 'fast' flag to 'reassoc')

Addressed review comments

Rebase to fetch merged dependency

This patch does not contain the full test to make changes more readable during the review.

Thanks for the review.
@frasercrmck, could you please submit the patch on my behalf? Author: Anton Sidorenko <anton.sidorenko@syntacore.com>

Addressed review comments

Apply VL shrinking only when SEW/LMUL ratio is unmodified. This change depends on D135086

Addressed review comments except for a few which have questions from my side.

Rebase

@arcbbb, could you please submit the patch on my behalf? Author: Anton Sidorenko <anton.sidorenko@syntacore.com>
Thanks.

Depends on D134179

Addressed review comments

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

A gentle ping

Make VL choosing for a splat-like VMV based on its users

A gentle ping on the question about adding a markup of merge operands for intrinsics.

In D130895#3691031, @craig.topper wrote:

What if the user is the merge operand of a tail undisturbed instruction. The VL of the using instruction would not apply to it then.