Place MLIR_RUN_RISCV_VECTOR_TESTS option under X86VECTOR.

Rebase.

I provide an environment setup document to show how to build the toolchain and perform the integration tests.

• Add integration test (test-riscvv-arithmetic, test-riscvv-memory, test-riscvv-stripmining).
• Add ConvertPolicyOperandOpToLLVMPattern and ConvertPassthruOperandOpToLLVMPattern for mask/tail policy in the RISC-V LLVM IR intrinsics.

Use the LLVM_AnyPointer constraints in LLVMOpBase.td instead of a local one.

• Some RISC-V + JIT progress (needed by integration test)

• Sync to the vector type with scalable dimensions.
• Set the vta as an attribute.
• Add setvl operation.

• Rebase
• Using OpAdaptor. sync to commit b54c72
• Adding vta argument. sync to commit 7d39a8
• Removing context argument from parse function. sync to commit fb093c

In D108536#3025499, @aartbik wrote:

Have you made more progress on this? I realize this is a bit of a hazzle, but leaving it as a TODO has a very high risk of not being done at all... :-(

• Naming (RVV -> RISCVV)
• Scalable Vector Type (Common Scalable Vector Type + Separate RISC-V Scalable Vector Type)
  • Lift Scalable Vector Type to Vector Dialect
  • Define RVV LMUL Type, RVV Mask Type, and RVV Vector Type
  • Implement Type Mapping Process

For the next step, I will try to give better semantics to the type of RVV:

• let the vector type directly map LMUL and SEW.
• add a type conversion when lower the RVV operation to RVV intrinsic operation.

• Fix typo.
• Lift the scalable vector type to vector dialect. The SVE and RVV can share the definition now.

As for the integration test, I currently encounter some problems, and I will continue to find some solutions. At the same time, I will try to move the scalable vector type into the vector dialect in the next step.

In D108536#2963181, @rriddle wrote:

nit on the naming, rvv feels a bit too general. I'd rather go with a longer name that spells out riscv: riscvv or something related.

• Add more background about RVV and introduction to operations in this dialect.
• Add CHECK-LABELs for the round trip test.
• Fix some format issues.

FYI - I wrote the RFC in the LLVM discourse.

Rebase.

I can't figure out why checking the numpy can fail the LLVM codegen test?

Add NumPy as a required component.

Check numpy in find_package by adding OPTIONAL_COMPONENTS NumPy.

I'm so sorry for the late reply because of the time zone difference, and thanks for your help and review!

I'm wondering can we use the MLIRDetectPythonEnv.cmake or names like this (detect all the required Python environments), instead of MLIRDetectPybind11.cmake (only responsible for checking pybind11). In this case, we can define all the detecting functions (like mlir_detect_numpy_install) in one cmake file to avoid fragmentation.

• Rebase.
• Use static_cast and add a comment.

• Set the buffer to read-only.
• Add note to Python binding doc to note that pybind11 v2.6.0 is required.
• Use llvm::SmallVector instead of std::vector.

This patch implements array property for dense elements attribute to get array. There is also a buffer protocol method in D91021.
Let's compare and choose one.

According to Stella's suggestion, there are two methods to get the array from dense elements attribute:

Add unit tests for mlirDenseElementsAttrGetRawData C API.

Rebase.

• Rebase.
• Remove the mlirElementsAttrGetType C API.
• Modify checking conditions and unify the use of braces of the if and if else in accessBuffer function.
• Unify the type into intptr_t in bufferInfo function.

• Add mlirDenseElementsAttrGetRawData C API.
• Use the raw data to avoid the allocated array in the buffer protocol.

Use the typeid/isa scheme, expose IsA and Get methods for each affine binary operation expression.

This should work:
cmake --build . --target install-MLIRBindingsPythonSources install-MLIRBindingsPythonExtension

LGTM, I use the following commands in the build directory:

cmake --build . --target check-mlir
cmake --build . --target install

I have a question that if I only want to install MLIRBindingsPythonExtension and MLIRBindingsPythonSources (without installing llvm, llvm-c, mlir, mlir-c, etc.), what should I do?

• Modify the comment for mlirFloatAttrDoubleGetChecked.
• Drop the _typed suffix for FloatAttr and IntegerAttr get methods.
• Change the parameter type of BoolAttr.get method to bool.
• Add get_f32 and get_f64 methods to FloatAttr.

LGTM, thanks!

Hi @ftynse - After pushing this patch, I received en email said that:

• Use intptr_t * for the `resultPos parameter in mlirAffineMapGetSubMap function.
• Use a vector to cast the element of resultPos from intptr_t to unsigned.

• unsigned -> intptr_t
• Place all the affine map C API back to AffineMap.h/.cpp
• Add Utils.h and move CallbackOstream to Utils.h to make sure it is available to mlirAffineMapPrint.

• Modify name of mlirAffineMap***Get functions.
• Use intptr_t for parameters related to sizes.
• Add details for the comments of the mlirAffineMapPermutationMapGet.