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>
This patch adds a warning that's emitted when a builtin call uses ZA
state but the calling function doesn't provide any.
Patch by David Sherwood <david.sherwood@arm.com>.
This PR adds a warning that's emitted when a non-streaming or
non-streaming-compatible builtin is called in an unsuitable function.
Uses work by Kerry McLaughlin.
This is a re-upload of #74064 and fixes a compile time increase.
This PR adds a warning that's emitted when a non-streaming or
non-streaming-compatible builtin is called in an unsuitable function.
Uses work by Kerry McLaughlin.
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.
This patch implements the builtins in Clang
and the LLVM-IR intrinsic for the following:
// Variants are also available for:
// _s8, _s16, _u16, _s32, _u32, _s64, _u64,
// _f16, _f32, _f64uint8x16_t svaddqv[_u8](svbool_t pg, svuint8_t zn);
// Variants are also available for:
// _s8, _u16, _s16, _u32, _s32, _u64, _s64
uint8x16_t svandqv[_u8](svbool_t pg, svuint8_t zn); uint8x16_t
sveorqv[_u8](svbool_t pg, svuint8_t zn); uint8x16_t svorqv[_u8](svbool_t
pg, svuint8_t zn);
// Variants are also available for:
// _s8, _u16, _s16, _u32, _s32, _u64, _s64;
uint8x16_t svmaxqv[_u8](svbool_t pg, svuint8_t zn); uint8x16_t
svminqv[_u8](svbool_t pg, svuint8_t zn);
// Variants are also available for _f32, _f64
float16x8_t svmaxnmqv[_f16](svbool_t pg, svfloat16_t zn); float16x8_t
svminnmqv[_f16](svbool_t pg, svfloat16_t zn);
According to the PR#257[1]
The reduction instruction uses scalable vectors as input and fixed
vectors as output, therefore we changed SVEEmitter to emit fixed vector
types in case the neon header(arm_neon.h) is not present.
[1]https://github.com/ARM-software/acle/pull/257
Co-author: Dinar Temirbulatov <dinar.temirbulatov@arm.com>
This patch is needed for the reduction instructions in sve2.1
It add a new header to sve with all the fixed vector types.
The new types are only added if neon is not declared.
This reverts commit 8434b0b9d3. #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.
Adds the following SME2 builtins:
- sv(add|sub)
- sv(add|sub)_za32/za64,
- sv(add|sub)_write_za32/za64
Other changes in this patch:
- CGBuiltin.cpp: The GetAArch64SMEProcessedOperands function is created
to avoid duplicating existing code from EmitAArch64SVEBuiltinExpr.
- arm_sve.td: The add/sub SME2 builtins which do not operate on ZA have
been added to arm_sve.td, matching the corrosponding LLVM IR intrinsic
names which start with @llvm.aarch64.sve for this reason.
- SveEmitter.cpp: Adds the createCoreHeaderIntrinsics function to remove
duplicated code in createHeader & createSMEHeader. Uses a new enum
(ACLEKind) to choose either "__builtin_sme_" or "__builtin_sve_" when
emitting the intrinsics.
See https://github.com/ARM-software/acle/pull/217/files
Previous representation used an enumeration combined to a switch to
dispatch to the appropriate lexer.
Use function pointer so that the dispatching is just an indirect call,
which is actually better because lexing is a costly task compared to a
function call.
This also makes the code slightly cleaner, speedup on compile time
tracker are consistent and range form -0.05% to -0.20% for NewPM-O0-g,
see
https://llvm-compile-time-tracker.com/compare.php?from=f9906508bc4f05d3950e2219b4c56f6c078a61ef&to=608c85ec1283638db949d73e062bcc3355001ce4&stat=instructions:u
Considering just the preprocessing task, preprocessing the sqlite
amalgametion takes -0.6% instructions (according to valgrind
--tool=callgrind)
---------
Co-authored-by: serge-sans-paille <sguelton@mozilla.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
This patch adds reinterpret builtins as proposed here:
https://github.com/ARM-software/acle/pull/275.
The builtins take the form:
sv<dst>x<N>_t svreinterpret_<dst>_<src>_x<N>(sv<src>x<N>_t op)
where
- <src> and <dst> designate the source and the destination type,
respectively, all pairs chosen from {s8, u8, s16, u8, s32, u32, s64,
u64, bf16, f16, f32, f64}
- <N> designated the number of tuple elements, 2, 3 or 4
A short (overloaded) for is also provided, where the destination type is
explicitly designated and the source type is deduced from the parameter
type. These take the form
sv<dst>x<N>_t svreinterpret_<dst>(sv<src>x<N>_t op)
For example:
svuin16x2_t svreinterpret_u16_s32_x2(svint32x2_t op);
svuin16x2_t svreinterpret_u16(svint32x2_t op);
Rather than write a bunch of logic to shepherd between enums with the
same sets of values, add the ability for EnumArgument to refer to an
external enum in the first place.
* Mark SVE ACLE types as substitution candidates.
* Change mangling of svbfloat16_t from __SVBFloat16_t to
__SVBfloat16_t.
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
This is an ABI break with the old behaviour available via
"-fclang-abi-compat=17".
- For a better understand of what the unsupported cases are, we add
more information to the debug note---a string of ancestor AST nodes
of the unclaimed DRE. For example, an unclaimed DRE p in an
expression `*(p++)` will result in a string starting with
`DRE ==> UnaryOperator(++) ==> Paren ==> UnaryOperator(*)`.
- To find out the most common patterns of those unsupported use cases,
we add a simple script to build a prefix tree over those strings and
count each prefix. The script reads input line by line, assumes a
line is a list of words separated by `==>`s, and builds a prefix tree
over those lists.
Reviewed by: t-rasmud (Rashmi Mudduluru), NoQ (Artem Dergachev)
Differential revision: https://reviews.llvm.org/D158561
1. The generated file contained a lot of duplicate switch cases, e.g.:
```
switch (Syntax) {
case AttributeCommonInfo::Syntax::AS_GNU:
return llvm::StringSwitch<int>(Name)
...
.Case("error", 1)
.Case("warning", 1)
.Case("error", 1)
.Case("warning", 1)
```
2. Some attributes were listed in wrong places, e.g.:
```
case AttributeCommonInfo::Syntax::AS_CXX11: {
if (ScopeName == "") {
return llvm::StringSwitch<int>(Name)
...
.Case("warn_unused_result", LangOpts.CPlusPlus11 ? 201907 : 0)
```
`warn_unused_result` is a non-standard attribute and should not be
available as [[warn_unused_result]].
3. Some attributes had the wrong version, e.g.:
```
case AttributeCommonInfo::Syntax::AS_CXX11: {
} else if (ScopeName == "gnu") {
return llvm::StringSwitch<int>(Name)
...
.Case("fallthrough", LangOpts.CPlusPlus11 ? 201603 : 0)
```
[[gnu::fallthrough]] is a non-standard spelling and should not have the
standard version. Instead, __has_cpp_attribute should return 1 for it.
There is another issue with attributes that share spellings, e.g.:
```
.Case("interrupt", true && (T.getArch() == llvm::Triple::arm || ...) ? 1 : 0)
.Case("interrupt", true && (T.getArch() == llvm::Triple::avr) ? 1 : 0)
...
.Case("interrupt", true && (T.getArch() == llvm::Triple::riscv32 || ...) ? 1 : 0)
```
As can be seen, __has_attribute(interrupt) would only return true for
ARM targets. This patch does not address this issue.
Differential Revision: https://reviews.llvm.org/D159393
This implements the [[msvc::no_unique_address]] attribute.
There is not ABI compatibility in this patch because the attribute is
relatively new and there's still some uncertainty in the MSVC version.
The recommit changes the attribute definitions so that instead of making
two separate attributes for no_unique_address
and msvc::no_unique_address, it modifies the attributes tablegen emitter
to allow spellings to be target-specific.
This reverts commit 71f9e7695b.
Inside `writePrettyPrintFunction()`, we check if we need to emit the
given argument:
```C++
if (!arg->isOptional() || arg->getIsOmitted() == "false") {
FoundNonOptArg = true;
continue;
}
```
For the `AssumeAligned` attribute, the second argument was optional, but
the `getIsOmitted()` returned `false`, thus we treated this argument as
**non-optional** in the end because of that disjunction.
It was because `getIsOmitted()` did not account for `Expr *` type, and
returned `false` on the fallthrough branch.
Fixes#67156
Currently there is no PrintOnLeft attribute set, which results in an
empty switch-case. When compiling this, MSVC issues a warning saying
that the switch-case is empty. Fix this by using a macro and checking
if this macro is defined or not.
Links to D157394
Previously clang AST prints the following declaration:
int fun_var_unused() {
int x __attribute__((unused)) = 0;
return x;
}
and
int __declspec(thread) x = 0;
as:
int fun_var_unused() {
int x = 0 __attribute__((unused));
return x;
}
and
int x = __declspec(thread) 0;
which is rejected by C/C++ parser. This patch modifies the logic to
print old C attributes for variables as:
int __attribute__((unused)) x = 0;
and the __declspec case as:
int __declspec(thread) x = 0;
Fixes: https://github.com/llvm/llvm-project/issues/59973
Previous version: D141714.
Differential Revision:https://reviews.llvm.org/D141714
The current generated ClangCommandLineReference.rst unconditionally
escapes underscores. This leads odd output on the website
https://clang.llvm.org/docs/ClangCommandLineReference.html
For example
-fchar8\_t, -fno-char8\_t
Whether an underscore should be escaped depends on the state. Currently
the escape routine doesn't keep track of the state and currently
underscores are not used in places where they need to be escaped.
Therefore remove the underscore from the list of escaped characters.
Otherwise these functions are not inlined when invoked from streaming
functions.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D159188
It was expressed in some reviews that Clang folks didn't want to hold
off other testing jobs in case clang-format failed. This patch makes
it so that the basic clang testing jobs will run even if clang-format
fails on the patch. The overall build will still be marked as failed,
but it will be possible to see the failures in clang tests so at least
there will be some feedback available.
The whole pipeline was originally blocked on clang-format because we
inherited that pipeline definition from libc++, where we want to block
on clang-format for capacity reasons.
Differential Revision: https://reviews.llvm.org/D159197
