History log of /llvm-project-15.0.7/clang/utils/TableGen/NeonEmitter.cpp (Results 1 – 25 of 154)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


1234567