LGTM, thanks!

@craig.topper @rogfer01 - do you have other comments?

LGTM. Other than that last comments.

Could you please purpose this implement in rvv-intrinsc-doc first?
I think this feature need to have discussion because store to nullptr is UB but we are making it as defined behavior only for these intrinsics.
Personally I like they have consistent behavior and in document side we just make a note for users that vl should not be a null pointer.

IMO, if I'm an user, I would not expected intrinsic function will generate the condition code to impact the performance, maybe we need to raise a issue in rvv-intrinsic-doc.

Store to null will be changed to unreachable, so all instructions after vleff intrinsic call will be deleted and it causes runtime errors. If destination to store is null, we won't extract and store the new vl.

IMO, maybe we could keep the DLLVM_BINUTILS_INCDIR option support but default is using the Plugin.h?

In D125323#3549794, @pcwang-thead wrote:

Is there an easy way to update tests? Or we need to add passthru operands manually? I will appreciate it if you can tell me. :-)

LGTM!

In D125546#3525173, @reames wrote:

Skimming through the code, is there any value in having a policy arg on slideup? If so, I might suggest adding it to both in an NFC change, and then doing a separate change to show the opt quality improvement.

LGTM, thanks.

In D125765#3526835, @pcwang-thead wrote:

In D125765#3524456, @khchen wrote:

I think we have no consensus in https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/18#issuecomment-817890161, and most people disagree the current naming,
maybe we need to have more followup discussion before landing this patch.

Thanks for your reminding of previous discussion!
Should we put this in next sync-up discussion agenda and settle it down? There are already some large code bases based GCC implementation, we should make it stable before it becomes too hard to change.

please move those tests to test/CodeGen/RISCV/rvv-intrinsics and rename them without rvv- prefix.

I think we have no consensus in https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/18#issuecomment-817890161, and most people disagree the current naming,
maybe we need to have more followup discussion before landing this patch.

LGTM, thanks!

Do we need to have some tests in clang/test/PCH/ for new #pragma?

Thanks Kito. This all LGTM except some warnings need to fix.

LGTM, thanks!

address Craig's comments, thanks!!

Thanks for refactoring!

address frasercrmck's comments, thanks!

I think maybe it's good to have pre-commit test to demonstrate VLS realistic cases could be benefited by this improvement, or at least mention realistic test are coming from VLS vectorization in commit message.

update comment.

Add zve64* tests.

LGTM. Thanks!

LGTM too.

It's seem like all targets need to return false in useFP16ConversionIntrinsics for correctness of int16 -> __fp16 conversion?

In D124187#3469484, @kito-cheng wrote:

It's already accepted and committed, but I just want to say thanks, @frasercrmck, I always need to spend time to decode that when I read the value in MIR, that really save my life.

RV32-ZVE32F and RV64-ZVE32F result are identical. Use ZVE32F prefix directly.

update clang tests.

In D124186#3465136, @craig.topper wrote:

The intrinsic interface doesn't care about 0<i<vstart for slidedown. We don't give user control of vstart. Nearly every instruction is undisturbed for 0<i<vstart.

But having said that it probably makes sense to keep the vslideup/down interface the same.

address @frasercrmck's comment. thanks!

In D124062#3461069, @frasercrmck wrote:

Were they perhaps passing because i64 [[VL:%.*]] was matching the , i64 0 too? Seems like a flaw in the checks generated by the script, but I can see how the majority of the time the brevity is nice.

LGTM, thanks!

Fix typo. Thanks!
It's good to update this chagned soon if it does make sense,
because I change the IR interface again...
I believe changing the IR interface frequently is annoying.

LGTM, thanks!!!