[llvm][RISCV] Support RISCV vector tuple type in llvm IR (#97992)

Summary:
This patch proposes new llvm types for RISCV vector tuples represented
as `TargetExtType` which contains both `LMUL` and

[llvm][RISCV] Support RISCV vector tuple type in llvm IR (#97992)

Summary:
This patch proposes new llvm types for RISCV vector tuples represented
as `TargetExtType` which contains both `LMUL` and `NF`(num_fields)
information and keep it all the way down to `selectionDAG` to match the
corresponding `MVT`(support in the following patch).

Detail:
Currently we have built-in C types for RISCV vector tuple type, e.g.
`vint32m1x2_t`, however it's is represented as structure of scalable
vector types, i.e. `{<vscale x 2 x i32>, <vscale x 2 x i32>}`. It loses
the information for num_fields(NF) as struct is flattened during
`selectionDAG`, thus it makes it not possible to handle inline assembly
of vector tuple type, it also makes the calling convention of vector
tuple types handing not strait forward and hard to realize the
allocation code, i.e. `RVVArgDispatcher`.

The llvm IR for the example above is then represented as
`target("riscv.vector.tuple", <vscale x 8 x i8>, 2)` in which the first
type parameter is the equivalent size scalable vecotr of i8 element
type, the following integer parameter is the `NF` of the tuple.

The new RISCV specific vector insert/extract intrinsics are also added
as `llvm.riscv.vector.insert` and `llvm.riscv.vector.extract` to handle
tuple type subvector insertion/extraction since the generic ones only
operates on `VectorType` but not `TargetExtType`.

There are total of 32 llvm types added for each `VREGS * NF <= 8`, where
`VREGS` is the vector registers needed for each `LMUL` and `NF` is
num_fields.
The name of types are:
```
target("riscv.vector.tuple", <vscale x 1 x i8>, 2) // LMUL = mf8, NF = 2
target("riscv.vector.tuple", <vscale x 1 x i8>, 3) // LMUL = mf8, NF = 3
target("riscv.vector.tuple", <vscale x 1 x i8>, 4) // LMUL = mf8, NF = 4
target("riscv.vector.tuple", <vscale x 1 x i8>, 5) // LMUL = mf8, NF = 5
target("riscv.vector.tuple", <vscale x 1 x i8>, 6) // LMUL = mf8, NF = 6
target("riscv.vector.tuple", <vscale x 1 x i8>, 7) // LMUL = mf8, NF = 7
target("riscv.vector.tuple", <vscale x 1 x i8>, 8) // LMUL = mf8, NF = 8
target("riscv.vector.tuple", <vscale x 2 x i8>, 2) // LMUL = mf4, NF = 2
target("riscv.vector.tuple", <vscale x 2 x i8>, 3) // LMUL = mf4, NF = 3
target("riscv.vector.tuple", <vscale x 2 x i8>, 4) // LMUL = mf4, NF = 4
target("riscv.vector.tuple", <vscale x 2 x i8>, 5) // LMUL = mf4, NF = 5
target("riscv.vector.tuple", <vscale x 2 x i8>, 6) // LMUL = mf4, NF = 6
target("riscv.vector.tuple", <vscale x 2 x i8>, 7) // LMUL = mf4, NF = 7
target("riscv.vector.tuple", <vscale x 2 x i8>, 8) // LMUL = mf4, NF = 8
target("riscv.vector.tuple", <vscale x 4 x i8>, 2) // LMUL = mf2, NF = 2
target("riscv.vector.tuple", <vscale x 4 x i8>, 3) // LMUL = mf2, NF = 3
target("riscv.vector.tuple", <vscale x 4 x i8>, 4) // LMUL = mf2, NF = 4
target("riscv.vector.tuple", <vscale x 4 x i8>, 5) // LMUL = mf2, NF = 5
target("riscv.vector.tuple", <vscale x 4 x i8>, 6) // LMUL = mf2, NF = 6
target("riscv.vector.tuple", <vscale x 4 x i8>, 7) // LMUL = mf2, NF = 7
target("riscv.vector.tuple", <vscale x 4 x i8>, 8) // LMUL = mf2, NF = 8
target("riscv.vector.tuple", <vscale x 8 x i8>, 2) // LMUL = m1, NF = 2
target("riscv.vector.tuple", <vscale x 8 x i8>, 3) // LMUL = m1, NF = 3
target("riscv.vector.tuple", <vscale x 8 x i8>, 4) // LMUL = m1, NF = 4
target("riscv.vector.tuple", <vscale x 8 x i8>, 5) // LMUL = m1, NF = 5
target("riscv.vector.tuple", <vscale x 8 x i8>, 6) // LMUL = m1, NF = 6
target("riscv.vector.tuple", <vscale x 8 x i8>, 7) // LMUL = m1, NF = 7
target("riscv.vector.tuple", <vscale x 8 x i8>, 8) // LMUL = m1, NF = 8
target("riscv.vector.tuple", <vscale x 16 x i8>, 2) // LMUL = m2, NF = 2
target("riscv.vector.tuple", <vscale x 16 x i8>, 3) // LMUL = m2, NF = 3
target("riscv.vector.tuple", <vscale x 16 x i8>, 4) // LMUL = m2, NF = 4
target("riscv.vector.tuple", <vscale x 32 x i8>, 2) // LMUL = m4, NF = 2
```

RFC:
https://discourse.llvm.org/t/rfc-support-riscv-vector-tuple-type-in-llvm/80005

show more ...

[clang] Construct SmallVector with ArrayRef (NFC) (#101898)

[RISCV] Remove unused RequiredFeatures argument from RVVIntrinsic constructor. NFC (#98067)

Looks like the usage was removed by
7a5cb15ea6facd82756adafae76d60f36a0b60fd

[RISCV][clang] Optimize memory usage of intrinsic lookup table (#77487)

This patch optimize:
1. Reduce string size of RVVIntrinsicDef.
2. Reduce the type size of the index of intrinsics.

I

[RISCV][clang] Optimize memory usage of intrinsic lookup table (#77487)

This patch optimize:
1. Reduce string size of RVVIntrinsicDef.
2. Reduce the type size of the index of intrinsics.

I use valgrind --tool=massif to analyze a simple program:
```
#include <riscv_vector.h>
vint32m1_t test(vint32m1_t v1, vint32m1_t v2, size_t vl) {
return __riscv_vadd(v1, v2, vl);
}
```
and before optimization, the peak memory usage is 15.68MB,
after optimization, the peak memory usage is 13.69MB.

show more ...

[Clang][RISCV] bfloat uses 'y' instead of 'b' (#76575)

Builtins.def says that bfloat should be represented by the 'y'
character, not the 'b' character. The 'b' character is specified to
represent

[Clang][RISCV] bfloat uses 'y' instead of 'b' (#76575)

Builtins.def says that bfloat should be represented by the 'y'
character, not the 'b' character. The 'b' character is specified to
represent boolean. The implementation currently uses 'b' correctly for
boolean and incorrectly re-uses 'b' for bfloat.

This was not caught since no builtins are emitted in
build/tools/clang/include/clang/Basic/riscv_sifive_vector_builtins.inc.
Don't know that we can test this without creating builtins that expose
this issue, although I'm not sure we really want to do that.

show more ...

[RISCV] Remove experimental from Vector Crypto extensions (#74213)

The RISC-V vector crypto extensions have been ratified. This patch
updates the Clang and LLVM support for these extensions to be

[RISCV] Remove experimental from Vector Crypto extensions (#74213)

The RISC-V vector crypto extensions have been ratified. This patch
updates the Clang and LLVM support for these extensions to be
non-experimental, while leaving the C intrinsics as experimental since
the C intrinsics are not yet standardized.

Co-authored-by: Brandon Wu <brandon.wu@sifive.com>

show more ...

[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}:

[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

Recommit "[Clang][RISCV] Introduce tuple types for RVV bfloat16 #72216" (#72370)

This PR attempts to recommit the PR (#72216) with a safe-bounded TypeID
that will not cause indeterminate results fo

Recommit "[Clang][RISCV] Introduce tuple types for RVV bfloat16 #72216" (#72370)

This PR attempts to recommit the PR (#72216) with a safe-bounded TypeID
that will not cause indeterminate results for the compiler.

show more ...

Revert "[Clang][RISCV] Introduce tuple types for RVV bfloat16 (#72216)" (#72367)

This reverts commit 8434b0b9d39b7ffcd1f7f7b5746151e293620e0d. #72216

This commit broke the multiple buildbots, lo

Revert "[Clang][RISCV] Introduce tuple types for RVV bfloat16 (#72216)" (#72367)

This reverts commit 8434b0b9d39b7ffcd1f7f7b5746151e293620e0d. #72216

This commit broke the multiple buildbots, looks like the extension in
`NUM_PREDEF_TYPE_IDS` might have broken some inheriting usages, causing
indeterminate results for the compiler. Investigating the issue now.

show more ...

[Clang][RISCV] Introduce tuple types for RVV bfloat16 (#72216)

The first commit extends the capacity from the compiler infrastructure,
and the second commit continues the effort in #71140 to introd

[Clang][RISCV] Introduce tuple types for RVV bfloat16 (#72216)

The first commit extends the capacity from the compiler infrastructure,
and the second commit continues the effort in #71140 to introduce tuple
types for bfloat16.

show more ...

[RISCV] Introduce and use BF16 in Xsfvfwmaccqqq intrinsics (#71140)

BF16 implementation based on @joshua-arch1's
https://reviews.llvm.org/D152498
Fixed the incorrect f16 type introduced in
https:

[RISCV] Introduce and use BF16 in Xsfvfwmaccqqq intrinsics (#71140)

BF16 implementation based on @joshua-arch1's
https://reviews.llvm.org/D152498
Fixed the incorrect f16 type introduced in
https://github.com/llvm/llvm-project/pull/68296

---------

Co-authored-by: Jun Sha (Joshua) <cooper.joshua@linux.alibaba.com>

show more ...

[RISCV] Support Xsfvfnrclipxfqf extensions (#68297)

FP32-to-int8 Ranged Clip Instructions

https://sifive.cdn.prismic.io/sifive/0aacff47-f530-43dc-8446-5caa2260ece0_xsfvfnrclipxfqf-spec.pdf

[clang] Stop including llvm/ADT/StringMap.h (NFC)

These source files do not use StringMap.h.

[RISCV] Support vector crypto extension C intrinsics

Depends on D141672, D138809

Differential Revision: https://reviews.llvm.org/D138810

[RISCV] Resolve a few bugs in RISCVVIntrinsicUtils.cpp

This patch does a few things:
1. Add a new type called Undefined to ScalarTypeKind.
2. Make RVVType::applyModifier early return when encoun

[RISCV] Resolve a few bugs in RISCVVIntrinsicUtils.cpp

This patch does a few things:
1. Add a new type called Undefined to ScalarTypeKind.
2. Make RVVType::applyModifier early return when encounter invalid
ScalarType, otherwise it could be modified to "non-invalid" type in the following code.
3. When FixedLMULType::SmallerThan is applied, the lmul should be "<" than
specified one, so lmuls which are ">=" should be marked as invalid.

Differential Revision: https://reviews.llvm.org/D156223

show more ...

[Clang][RISCV] Align RVV intrinsic builtin names with the C intrinsics

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D155102

[RISCV] Remove unused private field 'HasFRMRoundModeOp' in RVVIntrinsic (NFC)

/data/llvm-project/clang/include/clang/Support/RISCVVIntrinsicUtils.h:390:8: error: private field 'HasFRMRoundModeOp' is

[RISCV] Remove unused private field 'HasFRMRoundModeOp' in RVVIntrinsic (NFC)

/data/llvm-project/clang/include/clang/Support/RISCVVIntrinsicUtils.h:390:8: error: private field 'HasFRMRoundModeOp' is not used [-Werror,-Wunused-private-field]
bool HasFRMRoundModeOp;
^
1 error generated.

show more ...

[RISCV][POC] Model frm control for vfadd

Depends on D152879.

Specification PR: riscv-non-isa/rvv-intrinsic-doc#226

This patch adds variant of `vfadd` that models the rounding mode control.
The add

[RISCV][POC] Model frm control for vfadd

Depends on D152879.

Specification PR: riscv-non-isa/rvv-intrinsic-doc#226

This patch adds variant of `vfadd` that models the rounding mode control.
The added variant has suffix `_rm` appended to differentiate from the
existing ones that does not alternate `frm` and uses whatever is inside.

The value `7` is used to indicate no rounding mode change. Reusing the
semantic from the rounding mode encoding for scalar floating-point
instructions.

Additional data member `HasFRMRoundModeOp` is added so we can append
`_rm` suffix for the fadd variants that models rounding mode control.

Additional data member `IsRVVFixedPoint` is added so we can define
pseudo instructions with rounding mode operand and distinguish the
instructions between fixed-point and floating-point.

Reviewed By: craig.topper, kito-cheng

Differential Revision: https://reviews.llvm.org/D152996

show more ...

[RISCV] Remove redundant _ta suffix in RVV intrinsics builtins. NFC

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D154693

[3/11][Clang][RISCV] Expand all variants for unit stride segment load

This is the 3rd patch of the patch-set. For the cover letter, please
checkout D152069.

Depends on D152070.

This patch expands

[3/11][Clang][RISCV] Expand all variants for unit stride segment load

This is the 3rd patch of the patch-set. For the cover letter, please
checkout D152069.

Depends on D152070.

This patch expands all variants of unit stride segment load, including
the policy variants. This patch also fixes the trailing suffix in the
intrinsics' function name that representing the return type, adding
`x{NF}`.

Currently the tuple type co-exists with the non-tuple type intrinsics.
Since the co-existance is temporary, this patch only adds test cases of
all variants for vlseg2e32 to show the capability done.

Test cases of other data type and NF will be added in the patch-set
when the replacement happens.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D152071

show more ...

[2/11][Clang][RISCV] Expand all variants of RVV intrinsic tuple types

This is the 2nd patch of the patch-set. For the cover letter, please
checkout D152069.

Depends on D152069.

This patch also rem

[2/11][Clang][RISCV] Expand all variants of RVV intrinsic tuple types

This is the 2nd patch of the patch-set. For the cover letter, please
checkout D152069.

Depends on D152069.

This patch also removes redundant checks related to tuples and dedicate
the check to happen in `RVVType::verifyType`.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D152070

show more ...

[10/11][POC][Clang][RISCV] Define vget for tuple type

For the cover letter of this patch-set, please checkout D146872.

Depends on D147915.

This is the 10th patch of the patch-set.

This patch is a

[10/11][POC][Clang][RISCV] Define vget for tuple type

For the cover letter of this patch-set, please checkout D146872.

Depends on D147915.

This is the 10th patch of the patch-set.

This patch is a proof-of-concept and will be extended to full coverage
in the future. Only vget for tuple type of NF=2, EEW=32, LMUL=1 is
defined now.

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D147916

show more ...

[Clang][RISCV] Remove unused variable `IsTuple` for structure `RVVIntrinsic`

Signed-off by: eop Chen <eop.chen@sifive.com>

[3/11][POC][Clang][RISCV] Add typedef of the tuple type and define tuple type variant of vlseg2e32

For the cover letter of this patch-set, please checkout D146872.

Depends on D146873.

This is the

[3/11][POC][Clang][RISCV] Add typedef of the tuple type and define tuple type variant of vlseg2e32

For the cover letter of this patch-set, please checkout D146872.

Depends on D146873.

This is the 3rd patch of the patch-set. This patch originates from
D99593.

Note: This patch is a proof-of-concept and will be extended to full
coverage in the future. Currently, the old non-tuple unit-stride
segment load is not removed, and only signed integer unit-strided
segment load of NF=2, EEW=32 is defined here.

When replacing the old intrinsics, the extra `IsTuple` parameter under
various places will be redundant and removed.

Authored-by: eop Chen <eop.chen@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D147731

show more ...

[3/3][Clang][RISCV] Add `__riscv_` for overloaded intrinsics

This commit adds prefix for the overloaded RVV intrinsics.

This is the 3rd commit of a patch-set to add __riscv_ for all RVV
intrinsics.

[3/3][Clang][RISCV] Add `__riscv_` for overloaded intrinsics

This commit adds prefix for the overloaded RVV intrinsics.

This is the 3rd commit of a patch-set to add __riscv_ for all RVV
intrinsics.

This follows the naming guideline under riscv-c-api-doc to add the
`__riscv_` suffix for all RVV intrinsics.

Pull Request:
riscv-non-isa/riscv-c-api-doc#31
riscv-non-isa/rvv-intrinsic-doc#189

Depends on D142644.

Reviewed By: kito-cheng

Differential Revision: https://reviews.llvm.org/D142697

show more ...