Apply Philip's comment.

Apply Craig's comment.

Apply Craig's comment.

Add reviewers.

Apply spatel's comment.

Fix getDefaultVLOps name and implementation.

Fix vector_shuffle source may be extract_subvector and undef.

In D137704#3924114, @craig.topper wrote:

In D137704#3924102, @HanKuanChen wrote:

In D137704#3924088, @craig.topper wrote:

In D137704#3924065, @HanKuanChen wrote:

In D137704#3924061, @craig.topper wrote:

In D137704#3924035, @HanKuanChen wrote:

In D137704#3924007, @craig.topper wrote:

This test crashes

define void @vnsrl_2_undef_float(ptr %in, ptr %out) {
entry:
  %0 = load <32 x float>, ptr %in, align 4
  %1 = shufflevector <32 x float> %0, <32 x float> poison, <16 x i32> <i32 1, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  store <16 x float> %1, ptr %out, align 4
  ret void
}

I will merge and close https://reviews.llvm.org/D137904 to solve this test.

How does D137904 solve this? That patch is marked NFC

t7: v32f32,ch = load<(load (s1024) from %ir.in, align 4)> t0, t2, undef:i64
t9: v16f32 = extract_subvector t7, Constant:i64<0>
t11: v16f32 = vector_shuffle<1,3,u,u,u,u,u,u,u,u,u,u,u,u,u,u> t9, undef:v16f32

I expect we use getSingleShuffleSource to get t7 instead of t9. Then we check whether the type of source and destination can match vnsrl rule.
This test has a 2 Difference, and source is v32f32 and destination is v16f32, which is valid.

I don't think that will fix it. The same test crashes if you change the shuffle mask to <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15>. That cases should have two extract_subvectors.

May you provide the test?
I try <16 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef> and <8 x i32> <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15>, but I don't get the crash if getSingleShuffleSource is used (and check the source and destination type).

I was using Zvl128b not Zvl256b. Does that make a difference?

In D137704#3924088, @craig.topper wrote:

In D137704#3924065, @HanKuanChen wrote:

In D137704#3924061, @craig.topper wrote:

In D137704#3924035, @HanKuanChen wrote:

In D137704#3924007, @craig.topper wrote:

This test crashes

define void @vnsrl_2_undef_float(ptr %in, ptr %out) {
entry:
  %0 = load <32 x float>, ptr %in, align 4
  %1 = shufflevector <32 x float> %0, <32 x float> poison, <16 x i32> <i32 1, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  store <16 x float> %1, ptr %out, align 4
  ret void
}

I will merge and close https://reviews.llvm.org/D137904 to solve this test.

How does D137904 solve this? That patch is marked NFC

t7: v32f32,ch = load<(load (s1024) from %ir.in, align 4)> t0, t2, undef:i64
t9: v16f32 = extract_subvector t7, Constant:i64<0>
t11: v16f32 = vector_shuffle<1,3,u,u,u,u,u,u,u,u,u,u,u,u,u,u> t9, undef:v16f32

I expect we use getSingleShuffleSource to get t7 instead of t9. Then we check whether the type of source and destination can match vnsrl rule.
This test has a 2 Difference, and source is v32f32 and destination is v16f32, which is valid.

I don't think that will fix it. The same test crashes if you change the shuffle mask to <i32 1, i32 3, i32 5, i32 7, i32 9, i32 11, i32 13, i32 15>. That cases should have two extract_subvectors.

In D137704#3924089, @craig.topper wrote:

Am I correct in thinking that all of the tests are using LMUL=1 or fractional LMUL?

In D137704#3924061, @craig.topper wrote:

In D137704#3924035, @HanKuanChen wrote:

In D137704#3924007, @craig.topper wrote:

This test crashes

define void @vnsrl_2_undef_float(ptr %in, ptr %out) {
entry:
  %0 = load <32 x float>, ptr %in, align 4
  %1 = shufflevector <32 x float> %0, <32 x float> poison, <16 x i32> <i32 1, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  store <16 x float> %1, ptr %out, align 4
  ret void
}

I will merge and close https://reviews.llvm.org/D137904 to solve this test.

How does D137904 solve this? That patch is marked NFC

In D137704#3924007, @craig.topper wrote:

This test crashes

define void @vnsrl_2_undef_float(ptr %in, ptr %out) {
entry:
  %0 = load <32 x float>, ptr %in, align 4
  %1 = shufflevector <32 x float> %0, <32 x float> poison, <16 x i32> <i32 1, i32 3, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef, i32 undef>
  store <16 x float> %1, ptr %out, align 4
  ret void
}

Apply Craig's comment.

Fix pre-merge checks.

In D137635#3914902, @RKSimon wrote:

Do you have an upstream target that actually requires this?

Apply Craig's comments.

Contain pre-commit test only.

1. Fix Invalid rounding mode found.
2. Refactor and add getExactInteger.

LGTM

Add tests for -0.0 behavior.

In D133688#3784653, @craig.topper wrote:

Does this create -0.0 when it is supposed to?

1. Rename vle_vid-vfwcvt.ll to vle_vid-vfcvt.ll.

In D133688#3784653, @craig.topper wrote:

Does this create -0.0 when it is supposed to?

HI, the following code get infinite loop after this commit.

https://reviews.llvm.org/D128039 is accepted.

Update test.

Update test.

Add tag and more information in commit message.

Add tag in commit message.

VFRSQRT7 do not use FRM.
From v-spec,

The output value is independent of the dynamic rounding mode.

apply sentence advise

Apply grammar fix: is not exist -> does not exist