|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
5a2e56b7 |
| 23-Mar-2022 |
Nick Desaulniers <[email protected]> |
[Clang][NeonEmitter] emit ret decl first for -Wdeclaration-after-statement
The generated arm_neon.h header isn't -Wdeclaration-after-statement compliant when targeting -mbig-endian. Update the gener
[Clang][NeonEmitter] emit ret decl first for -Wdeclaration-after-statement
The generated arm_neon.h header isn't -Wdeclaration-after-statement compliant when targeting -mbig-endian. Update the generator to declare the return value, if any, first before any other arguments that might need to be "reversed" from little endian to big.
Another approach would have been to try to ignore this warning in system headers, though that might not be precise for tokens involved in macro expansion. See also: https://reviews.llvm.org/D116833#3236209.
Link: https://github.com/ClangBuiltLinux/linux/issues/1603 Fixes: https://github.com/llvm/llvm-project/issues/54062
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D122189
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
17d4bd3d |
| 09-Jan-2022 |
Kazu Hirata <[email protected]> |
[clang] Fix bugprone argument comments (NFC)
Identified with bugprone-argument-comment.
|
| #
f4ffcab1 |
| 01-Jan-2022 |
Kazu Hirata <[email protected]> |
Remove redundant string initialization (NFC)
Identified by readability-redundant-string-init.
|
| #
0542d152 |
| 26-Dec-2021 |
Kazu Hirata <[email protected]> |
Remove redundant string initialization (NFC)
Identified with readability-redundant-string-init.
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
16ceb44e |
| 25-Oct-2021 |
Kazu Hirata <[email protected]> |
[clang] Use llvm::{count,count_if,find_if,all_of,none_of} (NFC)
|
| #
4bd46501 |
| 25-Oct-2021 |
Kazu Hirata <[email protected]> |
Use llvm::any_of and llvm::none_of (NFC)
|
| #
dccfaddc |
| 21-Oct-2021 |
Kazu Hirata <[email protected]> |
[clang] Use StringRef::contains (NFC)
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
| #
2c25efcb |
| 22-Feb-2021 |
Ryan Santhiraraja <[email protected]> |
[AArch64] Adding SHA3 Intrinsics support
This patch adds the following SHA3 Intrinsics: vsha512hq_u64, vsha512h2q_u64, vsha512su0q_u64, vsha512su1q_u64 ve
[AArch64] Adding SHA3 Intrinsics support
This patch adds the following SHA3 Intrinsics: vsha512hq_u64, vsha512h2q_u64, vsha512su0q_u64, vsha512su1q_u64 veor3q_u8 veor3q_u16 veor3q_u32 veor3q_u64 veor3q_s8 veor3q_s16 veor3q_s32 veor3q_s64 vrax1q_u64 vxarq_u64 vbcaxq_u8 vbcaxq_u16 vbcaxq_u32 vbcaxq_u64 vbcaxq_s8 vbcaxq_s16 vbcaxq_s32 vbcaxq_s64
Note need to include +sha3 and +crypto when building from the front-end
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D96381
show more ...
|
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
| #
51d5991f |
| 05-Jan-2021 |
Florian Hahn <[email protected]> |
[Clang] Add AArch64 VCMLA LANE variants.
This patch adds the LANE variants for VCMLA on AArch64 as defined in "Arm Neon Intrinsics Reference for ACLE Q3 2020" [1]
This patch also updates `dup_typed
[Clang] Add AArch64 VCMLA LANE variants.
This patch adds the LANE variants for VCMLA on AArch64 as defined in "Arm Neon Intrinsics Reference for ACLE Q3 2020" [1]
This patch also updates `dup_typed` to accept constant type strings directly.
Based on a patch by Tim Northover.
[1] https://developer.arm.com/documentation/ihi0073/latest
Reviewed By: SjoerdMeijer
Differential Revision: https://reviews.llvm.org/D93014
show more ...
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
c70f3686 |
| 17-Dec-2020 |
Fangrui Song <[email protected]> |
Use basic_string::find(char) instead of basic_string::find(const char *s, size_type pos=0)
Many (StringRef) cannot be detected by clang-tidy performance-faster-string-find.
|
| #
a2f92214 |
| 06-Dec-2020 |
Fangrui Song <[email protected]> |
[TableGen] Delete 11 unused declarations
|
|
Revision tags: llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
| #
1b090db0 |
| 15-Jun-2020 |
Victor Campos <[email protected]> |
[ARM] Improve diagnostics message when Neon is unsupported
Summary: Whenever Neon is not supported, a generic message is printed:
error: "NEON support not enabled"
Followed by a series of other
[ARM] Improve diagnostics message when Neon is unsupported
Summary: Whenever Neon is not supported, a generic message is printed:
error: "NEON support not enabled"
Followed by a series of other error messages that are not useful once the first one is printed.
This patch gives a more precise message in the case where Neon is unsupported because an invalid float ABI was specified: the soft float ABI.
error: "NEON intrinsics not available with the soft-float ABI. Please use -mfloat-abi=softfp or -mfloat-abi=hard"
This message is the same one that GCC gives, so it is also making their diagnostics more compatible with each other.
Also, by rearranging preprocessor directives, these "unsupported" error messages are now the only ones printed out, which is also GCC's behaviour.
Differential Revision: https://reviews.llvm.org/D81847
show more ...
|
| #
3f353a2e |
| 23-Jun-2020 |
Mikhail Maltsev <[email protected]> |
[BFloat] Add convert/copy instrinsic support
This patch is part of a series implementing the Bfloat16 extension of the Armv8.6-a architecture, as detailed here:
https://community.arm.com/developer/
[BFloat] Add convert/copy instrinsic support
This patch is part of a series implementing the Bfloat16 extension of the Armv8.6-a architecture, as detailed here:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
Specifically it adds intrinsic support in clang and llvm for Arm and AArch64.
The bfloat type, and its properties are specified in the Arm Architecture Reference Manual:
https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
The following people contributed to this patch: - Alexandros Lamprineas - Luke Cheeseman - Mikhail Maltsev - Momchil Velikov - Luke Geeson
Differential Revision: https://reviews.llvm.org/D80928
show more ...
|
| #
5945e979 |
| 07-Jun-2020 |
Ties Stuij <[email protected]> |
[clang][BFloat] Add reinterpret cast intrinsics
Summary: This patch is part of a series implementing the Bfloat16 extension of the Armv8.6-a architecture, as detailed here:
https://community.arm.co
[clang][BFloat] Add reinterpret cast intrinsics
Summary: This patch is part of a series implementing the Bfloat16 extension of the Armv8.6-a architecture, as detailed here:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
The bfloat type, and its properties is specified in the Arm C language extension specification:
https://developer.arm.com/docs/ihi0055/d/procedure-call-standard-for-the-arm-64-bit-architecture
Subscribers: kristof.beyls, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79869
The following people contributed to this patch:
- Luke Cheeseman - Alexandros Lamprineas - Luke Geeson - Ties Stuij
show more ...
|
| #
a6fcf5ca |
| 05-Jun-2020 |
Ties Stuij <[email protected]> |
[clang][BFloat] add NEON emitter for bfloat
Summary: This patch adds the bfloat16_t struct typedefs (e.g. bfloat16x8x2_t) to arm_neon.h
This patch is part of a series implementing the Bfloat16 exte
[clang][BFloat] add NEON emitter for bfloat
Summary: This patch adds the bfloat16_t struct typedefs (e.g. bfloat16x8x2_t) to arm_neon.h
This patch is part of a series implementing the Bfloat16 extension of the Armv8.6-a architecture, as detailed here:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
The bfloat type, and its properties are specified in the Arm Architecture Reference Manual:
https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
The following people contributed to this patch: - Luke Cheeseman - Simon Tatham - Ties Stuij
Reviewers: t.p.northover, fpetrogalli, sdesmalen, az, LukeGeeson
Reviewed By: fpetrogalli
Subscribers: SjoerdMeijer, LukeGeeson, pbarrio, mgorny, kristof.beyls, ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79708
show more ...
|
| #
1e447318 |
| 05-Jun-2020 |
Ties Stuij <[email protected]> |
[ARM] Add poly64_t on AArch32.
Summary: The poly64 types are guarded with ifdefs for AArch64 only. This is wrong. This was also incorrectly documented in the ACLE spec, but this has been rectified i
[ARM] Add poly64_t on AArch32.
Summary: The poly64 types are guarded with ifdefs for AArch64 only. This is wrong. This was also incorrectly documented in the ACLE spec, but this has been rectified in the latest release. See paragraph 13.1.2 "Vector data types":
https://developer.arm.com/docs/101028/latest
This patch was written by Alexandros Lamprineas.
Reviewers: ostannard, sdesmalen, fpetrogalli, labrinea, t.p.northover, LukeGeeson
Reviewed By: ostannard
Subscribers: pbarrio, LukeGeeson, kristof.beyls, danielkiss, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79711
show more ...
|
| #
4ccb6c36 |
| 02-Jun-2020 |
Richard Smith <[email protected]> |
Fix violations of [basic.class.scope]p2.
These cases all follow the same pattern:
struct A { friend class X; //... class X {}; };
But 'friend class X;' injects 'X' into the surrounding names
Fix violations of [basic.class.scope]p2.
These cases all follow the same pattern:
struct A { friend class X; //... class X {}; };
But 'friend class X;' injects 'X' into the surrounding namespace scope, rather than introducing a class member. So the second 'class X {}' is a completely different type, which changes the meaning of the earlier name 'X' from '::X' to 'A::X'.
Additionally, the friend declaration is pointless -- members of a class don't need to be befriended to be able to access private members.
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4 |
|
| #
f56550cf |
| 05-Mar-2020 |
Lucas Prates <[email protected]> |
[ARM] Enabling range checks on Neon intrinsics' lane arguments
Summary: Range checks were not properly performed in the lane arguments of Neon intrinsics implemented based on splat operations. Calls
[ARM] Enabling range checks on Neon intrinsics' lane arguments
Summary: Range checks were not properly performed in the lane arguments of Neon intrinsics implemented based on splat operations. Calls to those intrinsics where translated to `__builtin__shufflevector` calls directly by the pre-processor through the arm_neon.h macros, missing the chance for the proper range checks.
This patch enables the range check by introducing an auxiliary splat instruction in arm_neon.td, delaying the translation to shufflevector calls to CGBuiltin.cpp in clang after the checks were performed.
Reviewers: jmolloy, t.p.northover, rsmith, olista01, ostannard
Reviewed By: ostannard
Subscribers: ostannard, dnsampaio, danielkiss, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74619
show more ...
|
| #
d4271162 |
| 05-Mar-2020 |
Lucas Prates <[email protected]> |
[ARM] Creating 'call_mangled' for Neon intrinsics definitions
Summary: As multiple versions of the same Neon intrinsic can be created through the same TableGen definition with the same argument type
[ARM] Creating 'call_mangled' for Neon intrinsics definitions
Summary: As multiple versions of the same Neon intrinsic can be created through the same TableGen definition with the same argument types, the existing `call` operator is not always able to properly perform overload resolutions.
As these different intrinsic versions are differentiated later on by the NeonEmitter through name mangling, this patch introduces a new `call_mangled` operator to the TableGen definitions, which allows a call for an otherwise ambiguous intrinsic by matching its mangled name with the mangled variation of the caller.
Reviewers: jmolloy, t.p.northover, rsmith, olista01, dnsampaio
Reviewed By: dnsampaio
Subscribers: dnsampaio, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74618
show more ...
|
| #
7bf23563 |
| 19-Mar-2020 |
Lucas Prates <[email protected]> |
Revert "[ARM] Setting missing isLaneQ attribute on Neon Intrisics definitions"
This reverts commit 62ab15ffa3f910c36758e99324deac12ee006c90.
Multiple commits were unintentionally squashed into this
Revert "[ARM] Setting missing isLaneQ attribute on Neon Intrisics definitions"
This reverts commit 62ab15ffa3f910c36758e99324deac12ee006c90.
Multiple commits were unintentionally squashed into this one. Reverting so each of them can be pushed properly.
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc3 |
|
| #
62ab15ff |
| 18-Feb-2020 |
Lucas Prates <[email protected]> |
[ARM] Setting missing isLaneQ attribute on Neon Intrisics definitions
Summary: Some of the `*_laneq` intrinsics defined in arm_neon.td were missing the setting of the `isLaneQ` attribute. This patch
[ARM] Setting missing isLaneQ attribute on Neon Intrisics definitions
Summary: Some of the `*_laneq` intrinsics defined in arm_neon.td were missing the setting of the `isLaneQ` attribute. This patch sets the attribute on the related definitions, as they will be required to properly perform range checks on their lane arguments.
Reviewers: jmolloy, t.p.northover, rsmith, olista01, dnsampaio
Reviewed By: dnsampaio
Subscribers: dnsampaio, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74616
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
| #
adcd0268 |
| 28-Jan-2020 |
Benjamin Kramer <[email protected]> |
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly m
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
show more ...
|
|
Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
78ad22e0 |
| 11-Oct-2019 |
Tim Northover <[email protected]> |
Recommit ARM-NEON: make type modifiers orthogonal and allow multiple modifiers.
The modifier system used to mutate types on NEON intrinsic definitions had a separate letter for all kinds of transfor
Recommit ARM-NEON: make type modifiers orthogonal and allow multiple modifiers.
The modifier system used to mutate types on NEON intrinsic definitions had a separate letter for all kinds of transformations that might be needed, and we were quite quickly running out of letters to use. This patch converts to a much smaller set of orthogonal modifiers that can be applied together to achieve the desired effect.
When merging with downstream it is likely to cause a conflict with any local modifications to the .td files. There is a new script in utils/convert_arm_neon.py that was used to convert all .td definitions and I would suggest running it on the last downstream version of those files before this commit rather than resolving conflicts manually.
The original version broke vcreate_* because it became a macro and didn't apply the normal integer promotion rules before bitcasting to a vector. This adds a temporary.
show more ...
|
| #
21f26470 |
| 25-Nov-2019 |
Hans Wennborg <[email protected]> |
Revert 3f91705ca54 "ARM-NEON: make type modifiers orthogonal and allow multiple modifiers."
This broke the vcreate_u64 intrinsic. Example:
$ cat /tmp/a.cc #include <arm_neon.h>
void g() {
Revert 3f91705ca54 "ARM-NEON: make type modifiers orthogonal and allow multiple modifiers."
This broke the vcreate_u64 intrinsic. Example:
$ cat /tmp/a.cc #include <arm_neon.h>
void g() { auto v = vcreate_u64(0); } $ bin/clang -c /tmp/a.cc --target=arm-linux-androideabi16 -march=armv7-a /tmp/a.cc:4:12: error: C-style cast from scalar 'int' to vector 'uint64x1_t' (vector of 1 'uint64_t' value) of different size auto v = vcreate_u64(0); ^~~~~~~~~~~~~~ /work/llvm.monorepo/build.release/lib/clang/10.0.0/include/arm_neon.h:4144:11: note: expanded from macro 'vcreate_u64' __ret = (uint64x1_t)(__p0); \ ^~~~~~~~~~~~~~~~~~
Reverting until this can be investigated.
> The modifier system used to mutate types on NEON intrinsic definitions had a > separate letter for all kinds of transformations that might be needed, and we > were quite quickly running out of letters to use. This patch converts to a much > smaller set of orthogonal modifiers that can be applied together to achieve the > desired effect. > > When merging with downstream it is likely to cause a conflict with any local > modifications to the .td files. There is a new script in > utils/convert_arm_neon.py that was used to convert all .td definitions and I > would suggest running it on the last downstream version of those files before > this commit rather than resolving conflicts manually.
show more ...
|
| #
3f91705c |
| 11-Oct-2019 |
Tim Northover <[email protected]> |
ARM-NEON: make type modifiers orthogonal and allow multiple modifiers.
The modifier system used to mutate types on NEON intrinsic definitions had a separate letter for all kinds of transformations t
ARM-NEON: make type modifiers orthogonal and allow multiple modifiers.
The modifier system used to mutate types on NEON intrinsic definitions had a separate letter for all kinds of transformations that might be needed, and we were quite quickly running out of letters to use. This patch converts to a much smaller set of orthogonal modifiers that can be applied together to achieve the desired effect.
When merging with downstream it is likely to cause a conflict with any local modifications to the .td files. There is a new script in utils/convert_arm_neon.py that was used to convert all .td definitions and I would suggest running it on the last downstream version of those files before this commit rather than resolving conflicts manually.
show more ...
|