we don't need this patch because we already handle the empty target-abi module flag now.

I'm not working on RISC-V now and please reference https://reviews.llvm.org/D132843#3770454 to see the follow-up work.

I'm not working on RISC-V now and please reference https://reviews.llvm.org/D132843#3770454 to see the follow-up work.

D135327 fixed this issue.

LGTM. Thanks for clean up code!

LGTM, thanks!!

LGTM, thanks!

Possible solution/results:

1. All functions in a.o and b.o using same target features during the first build stage, -march=rv64gc for a.o, -march=rv64g for b.o, and -march option given in LTO CodeGen stage is ignored, it only used for ELF attribute use (this revision).
2. All functions in a.o and b.o using same target features during the first build stage, -march=rv64gc for a.o, -march=rv64g for b.o, and deduced arch info from those .o for ELF attribute use (D106347), -march
3. All functions in a.o and b.o re-compile with -march=rv64gc_zba and ELF attribute use rv64gc_zba.

Option 1: Require user use right -march option during LTO stage, and might fill wrong/unexpected ELF attribute if give wrong -march or not even not given in LTO stage.
Option 2: Should be more ideal, but D106347 seems no progress for a while.
Option 3: This option will break IFUNC usage.

In D71387#3755056, @lewis-revill wrote:

I believe this patch is still relevant/necessary when using LTO for RISCV, so can I ask if @khchen is able to update it to rebase/address the feedback? If not, are there are any objections to me commandeering this revision to get it landed?

@nlopes we will update all undef to poison in follow up patches.

oops.. all tests need to updated and include all intrinsic IR tests...
Is there any benefit to switch UndefValue to PoisonValue?
maybe those changed should be in other follow-up patches?

In D126745#3691544, @craig.topper wrote:

In D126745#3691528, @khchen wrote:

In D126745#3678776, @nlopes wrote:

While at it, could you switch those UndefValue with PoisonValue if possible? Thank you!

I'm not sure UndefValue will work because the backend would only check isUndef() to generate correct code...

PoisonValue and UndefValue are both turned into undef in SelectionDAG today.

In D126745#3678776, @nlopes wrote:

While at it, could you switch those UndefValue with PoisonValue if possible? Thank you!

rebase and address @fakepaper56 and @StephenFan's comments, also do some refactoring.

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?