Add VRM2, VRM4 and VRM8 to CalleeSaved register list.

Update commit message.

RVVArgDispatcher is the class used to compute and maximize the register usage by using the vector argument information placed in std::vector<RVVArgInfo>, it's both used by frontend and backend.
Currently I'm not sure where is the better file to place this class, so I just place it in RISCVTargetParser.h.

Finish handling vector arguments in backend.

Resolved MaskRay's comments.

In D146054#4596571, @MaskRay wrote:

In D146054#4587210, @4vtomat wrote:

In D146054#4586067, @MaskRay wrote:

I think the best place to test RISCVISAInfo.cpp is llvm/unittests/Support/RISCVISAInfoTest.cpp.

clang/test/Driver/print-supported-extensions.c can test just a few lines (there will be some overlap with the testing in llvm/unittests/Support/RISCVISAInfoTest.cpp), so that changes to RISC-V extensions will generally not require updates to clang/test/Driver/print-supported-extensions.c

The goal of this patch is to list the supported extensions and their versions by providing an option, so I guess clang/test/Driver/print-supported-extensions.c aims differently with llvm/unittests/Support/RISCVISAInfoTest.cpp which is testing the functionalities in RISCVISAInfoTest.cpp.
clang/test/Driver/print-supported-extensions.c only tracks the extensions added and the their version changes and riscvExtensionsHelp in llvm/lib/Support/RISCVISAInfo.cpp doesn't have any input or output as well as any side effect, it only reads SupportedExtensions and SupportedExperimentalExtensions and dump the information.
So I think clang/test/Driver/print-supported-extensions.c is enough for this patch?

My comment is about: the test is placed at the wrong layer. See https://maskray.me/blog/2021-08-08-toolchain-testing#the-test-checks-at-the-wrong-layer

I don't want that RISC-V development in LLVM causes repeated changes to clang/test/Driver.

Update Craig's comment.

Update test cases.

Address Craig's comments.

In D158067#4597660, @craig.topper wrote:

In D158067#4597654, @4vtomat wrote:

In D158067#4592569, @craig.topper wrote:

Should Zvkb and Zvbb be in this list?

void RISCVIntrinsicManagerImpl::ConstructRVVIntrinsics(                          
    ArrayRef<RVVIntrinsicRecord> Recs, IntrinsicKind K) {                        
  const TargetInfo &TI = Context.getTargetInfo();                                
  static const std::pair<const char *, uint8_t> FeatureCheckList[] = {           
      {"64bit", RVV_REQ_RV64},                                                   
      {"xsfvcp", RVV_REQ_Xsfvcp}};

If we add Zvkb and Zvbb to the list, we should also add other vector crypto extensions to the list right?

Yes. Should be a different patch I suppose

In D158067#4592569, @craig.topper wrote:

Should Zvkb and Zvbb be in this list?

void RISCVIntrinsicManagerImpl::ConstructRVVIntrinsics(                          
    ArrayRef<RVVIntrinsicRecord> Recs, IntrinsicKind K) {                        
  const TargetInfo &TI = Context.getTargetInfo();                                
  static const std::pair<const char *, uint8_t> FeatureCheckList[] = {           
      {"64bit", RVV_REQ_RV64},                                                   
      {"xsfvcp", RVV_REQ_Xsfvcp}};

Update llvm/docs/RISCVUsage.rst.

Update commit message.

Add an option to deduce vector cc(default off).

1. Apply clang-format for this patch
2. Replace FileCheck --implicit-check-not=warning: with %clang -Werror

In D146054#4586067, @MaskRay wrote:

I think the best place to test RISCVISAInfo.cpp is llvm/unittests/Support/RISCVISAInfoTest.cpp.

clang/test/Driver/print-supported-extensions.c can test just a few lines (there will be some overlap with the testing in llvm/unittests/Support/RISCVISAInfoTest.cpp), so that changes to RISC-V extensions will generally not require updates to clang/test/Driver/print-supported-extensions.c

Ping

LGTM, but leave final decision to other reviewers~

LGTM, thanks!

LGTM, thanks~

Rename the function in the test case.

Add test cases.

In D138810#4571579, @dyung wrote:

The test you added clang/test/Sema/zvk-invalid.c is failing on bots, for example https://lab.llvm.org/buildbot/#/builders/139/builds/47055.

Is the test missing a REQUIRES: riscv-registered-target line by any chance?

This update does a few things:

1. Update test cases based on rvv-intrinsic-doc.
2. Add checks for "zvknh[a|b]" instructions.
3. Rename and restructure the function from CheckInvalidEGW to CheckInvalidVLENandLMUL.

Update missing comment.

This update does a few things:

1. Update Craig's comments.
2. Make LMUL=8 valid(https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/234#discussion_r1282568330).
3. Rebase.

Update Craig's comment.

Resolved Craig's comment.

Resolved Craig's comment.

Updated test case.

Resolved MaskRay's comments.

Resolved Aaron's comments.
Also group some code and refactoring some code to make it much clear.

Rebase

Resolved MaskRay's comments, thanks for reviewing!!

In D154576#4483919, @lhtin wrote:

In D154576#4476300, @4vtomat wrote:

In D154576#4476291, @craig.topper wrote:

Does this only change the calling convention when __attribute__((riscv_vector_cc)) is used? The attribute should be mentioned in the patch description.

Yes it only changes when __attribute__((riscv_vector_cc)) is used, thanks for reminding, I will mention in the description.

In addition to using attributes, functions that use vector registers to pass arguments or return values also need to comply with the new calling convention.

Resolved Craig's comment.

After discusstion in https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/234,
we will have multiple lmuls for scalar type operands.
Currently the test cases for those instructions are only presented in vaesdf,
all other instructions test cases will be copied from rvv-intrinsic-doc once
they're ready.
Also added test case for sema checking for checking valid lmul.

Resolved Craig's comments.

This update includes:

1. Add the constraint: LMUL*VLEN < EGW during lowering instructions.
2. Enumerate over all of lmul less or equal to vd type's lmul for those instructions that have scalar operand.

Add a test case for invalid example.