| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For each intrinsic with ManualCodegen block will generate something like
below:
```cpp
SegInstSEW = 0;
...
if (SegInstSEW == (unsigned)-1) {
auto PointeeType = E->getArg(4294967295)->getType()->getPointeeType();
SegInstSEW = llvm::Log2_64(getContext().getTypeSize(PointeeType));
}
```
But actually SegInstSEW is table-gen-time constant, so can remove that
if-check and directly use the constant.
This change reduce riscv_vector_builtin_cg.inc around 6600 lines (30913
to 24305) which is around 20% reduction, however seems this isn't impact
the build time much since the redundant dead branch is almost will
optimized away by compiler in early stage.
|
|
Current approach generates intrinsic records when users specify
corresponding required features by using command line option.
However it's not able to handle features passed by using target
attributes correctly where each function might have different
features.
This patch resolves this by generating all of intrinsic records which
carry the required features in their function declaration using
attribute and check the required extensions in CheckBuiltinFunctionCall.
This should fix
[56592](https://github.com/llvm/llvm-project/issues/56592),
[134962](https://github.com/llvm/llvm-project/issues/134962) and
[121603](https://github.com/llvm/llvm-project/issues/121603)
|
|
This patch implements clang intrinsic support for XAndesVDot.
The document for the intrinsics can be found at:
https://github.com/andestech/andes-vector-intrinsic-doc/blob/ast-v5_4_0-release-v5/auto-generated/andes-v5/intrinsic_funcs.adoc#andes-vector-dot-product-extensionxandesvdot
and with policy variants
https://github.com/andestech/andes-vector-intrinsic-doc/blob/ast-v5_4_0-release-v5/auto-generated/andes-v5/policy_funcs/intrinsic_funcs.adoc#andes-vector-dot-product-extensionxandesvdot
Co-authored-by: Tony Chuan-Yue Yuan <yuan593@andestech.com>
|
|
This patch implements clang intrinsic support for XAndesVPackFPH.
The document for the intrinsics can be found at:
https://github.com/andestech/andes-vector-intrinsic-doc/blob/ast-v5_4_0-release-v5/auto-generated/andes-v5/intrinsic_funcs.adoc#andes-vector-packed-fp16-extensionxandesvpackfph
and with policy variants
https://github.com/andestech/andes-vector-intrinsic-doc/blob/ast-v5_4_0-release-v5/auto-generated/andes-v5/policy_funcs/intrinsic_funcs.adoc#andes-vector-packed-fp16-extensionxandesvpackfph
Co-authored-by: Tony Chuan-Yue Yuan <yuan593@andestech.com>
|
|
We add comment markers and print enum names instead of numbers.
For required extensions, we print the feature list instead of raw
bits.
This recommits d0cf5cd which was reverted by 21ff45d.
|
|
(#133710)"
This reverts commit d0cf5cd5f9790dc21396936d076389c3be1a9599.
Error: "declaration of ‘clang::RISCV::RequiredExtensions
{anonymous}::SemaRecord::RequiredExtensions’ changes meaning of
‘RequiredExtensions’ [-fpermissive]"
|
|
We add comment markers and print enum names instead of numbers.
For required extensions, we print the feature list instead of raw
bits.
|
|
extensions. NFC (#132895)
We have more than 32 extensions in our downstream and had to change this
type from uint32_t to uint64_t.
To simplify our downstream and make the code more flexible, I propose to
make it an array of uint32_t that we can size based on the number of
extensions. I really wanted to use std::bitset, but we have to print the
bits to a .inc file which can't easily be done with std::bitset.
|
|
This lets the TableGen-ed code be much cleaner, directly building an
efficient string table without duplicates and without the repeated
prefix.
|
|
The spec:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/releases/tag/v1.0.0-rc4
Also remove __riscv_v_intrinsic_overloading since it's no longer in
spec, the overloading intrinsics should be also enabled when RVV
intrinsics are defined.
|
|
|
|
Identified with misc-include-cleaner.
|
|
|
|
intrinsics (#111476)
Indexed segment load/store intrinsics don't have SEW information encoded
in the name, so we need to get the information from its pointer type
argument at runtime.
|
|
Remove llvm:: from .cpp files, and add "using namespace llvm" if needed.
|
|
Change RISCVVEmitter to use const RecordKeeper.
This is a part of effort to have better const correctness in TableGen
backends:
https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
|
|
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
|
|
(#101811)
Fix https://github.com/llvm/llvm-project/issues/101526
`vf[n|w]cvt.x[|u].f` for f16 needs `zvfh` instead of `zvfhmin`, current
approach
is not able to detect this. Ultimately we need to add `zvfh` to
RequiredFeatures
to check other intrinsics instead, the type check should be done in
checkRVVTypeSupport.
|
|
constructor. NFC (#98067)
Looks like the usage was removed by
7a5cb15ea6facd82756adafae76d60f36a0b60fd
|
|
It follows the interface defined here:
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/293
|
|
__attribute__((target("arch=+v"))) (#83674)
It is currently not possible to use "RVV type" and "RVV intrinsics" if
the "zve32x" is not enabled globally. However in some cases we may want
to use them only in some functions, for instance:
```
#include <riscv_vector.h>
__attribute__((target("+zve32x")))
vint32m1_t rvv_add(vint32m1_t v1, vint32m1_t v2, size_t vl) {
return __riscv_vadd(v1, v2, vl);
}
int other_add(int i1, int i2) {
return i1 + i2;
}
```
, it is supposed to be compilable even the vector is not specified, e.g.
`clang -target riscv64 -march=rv64gc -S test.c`.
|
|
This helps debuggers to display values in bit-fields in a more helpful way.
|
|
|
|
to Zvfhmin (#77866)
From #75735, Zvfh implies Zvfhmin.
|
|
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.
|
|
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>
|
|
Remove ptr-to-ptr bitcast which was added back in
939352b6ec31db4e8defe07856868438fbc5340d . With opaque pointers, the
bitcast is now redundant.
Opaque ptr cleanup effort.
|
|
This PR attempts to recommit the PR (#72216) with a safe-bounded TypeID
that will not cause indeterminate results for the compiler.
|
|
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.
|
|
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.
|
|
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>
|
|
FP32-to-int8 Ranged Clip Instructions
https://sifive.cdn.prismic.io/sifive/0aacff47-f530-43dc-8446-5caa2260ece0_xsfvfnrclipxfqf-spec.pdf
|
|
Bfloat16 Matrix Multiply Accumulate Instruction
https://sifive.cdn.prismic.io/sifive/c391d53e-ffcf-4091-82f6-c37bf3e883ed_xsfvfwmaccqqq-spec.pdf
|
|
|
|
SiFive Int8 Matrix Multiplication Extensions Specification
https://sifive.cdn.prismic.io/sifive/c4f0e51d-4dd3-402a-98bc-1ffad6011259_int8-matmul-spec.pdf
|
|
The current condition causes assert failing if try to add a new vendor
vector file which only contains the same type signature.
|
|
|
|
Differential Revision: https://reviews.llvm.org/D158257
|
|
This patch adds the Zvfhmin extension for clang.
Reviewed By: craig.topper, michaelmaitland
Differential Revision: https://reviews.llvm.org/D150253
|
|
Specification PR: riscv-non-isa/rvv-intrinsic-doc#256
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D158402
|
|
The full multiply intrinsics are not included for EEW=64 in Zve64*.
They require the V extension to be enabled.
This commit improves diagnostic message from
```
<source>:4:10: error: call to undeclared function '__riscv_vsmul_vv_i64m1';
4 | return __riscv_vsmul_vv_i64m1(op1, op2, __RISCV_VXRM_RNU, vl);
```
to
```
test.c:5:10: error: builtin requires: v
5 | return __riscv_vsmul_vv_i64m1(op1, op2, __RISCV_VXRM_RNU, vl);
```
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155416
|
|
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
|
|
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
|
|
have a masked version. NFC
The function should not be called if an intrinsic does not have a masked version.
Signed-off by: eop Chen <eop.chen@sifive.com>
|
|
This reverts commit 35a0079238ce9fc36cdc8c6a2895eb5538bf7b4a.
The backend support is not present yet. The intrinsics will crash
the compiler if compiled to assembly or binary.
|
|
This patch adds the Zvfhmin extension for clang.
Reviewed By: craig.topper, michaelmaitland
Differential Revision: https://reviews.llvm.org/D150253
|
|
Signed-off by: eop Chen <eop.chen@sifive.com>
|
|
Signed-off by: eop Chen <eop.chen@sifive.com>
|
|
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
|
|
Add SiFive extension support
Depends on D147934
Differential Revision: https://reviews.llvm.org/D147935
|
