Author: David Green
Date: 2022-09-29T12:16:13+01:00
New Revision: e6171e87e16c59df5fba642d1f48de6f0a2d93d8
URL:
https://github.com/llvm/llvm-project/commit/e6171e87e16c59df5fba642d1f48de6f0a2d93d8
DIFF:
https://github.com/llvm/llvm-project/commit/e6171e87e16c59df5fba642d1f48de6f0a2d93d8.diff
L
Author: David Green
Date: 2022-10-01T15:40:59+01:00
New Revision: 781b491bba9d798e53f7784dced3c2be77c81dd4
URL:
https://github.com/llvm/llvm-project/commit/781b491bba9d798e53f7784dced3c2be77c81dd4
DIFF:
https://github.com/llvm/llvm-project/commit/781b491bba9d798e53f7784dced3c2be77c81dd4.diff
L
Author: David Green
Date: 2022-10-01T16:14:00+01:00
New Revision: 6dc5f3ec89748f2aa7cface6698bdcd27c8b329e
URL:
https://github.com/llvm/llvm-project/commit/6dc5f3ec89748f2aa7cface6698bdcd27c8b329e
DIFF:
https://github.com/llvm/llvm-project/commit/6dc5f3ec89748f2aa7cface6698bdcd27c8b329e.diff
L
Author: David Green
Date: 2022-10-01T18:26:42+01:00
New Revision: d7804e187a8fc90bde2c12e373aff85a1148b5e7
URL:
https://github.com/llvm/llvm-project/commit/d7804e187a8fc90bde2c12e373aff85a1148b5e7
DIFF:
https://github.com/llvm/llvm-project/commit/d7804e187a8fc90bde2c12e373aff85a1148b5e7.diff
L
Author: David Green
Date: 2022-10-03T15:27:23+01:00
New Revision: 4987ae84622b804e72c405aacbe297f0e5e247c7
URL:
https://github.com/llvm/llvm-project/commit/4987ae84622b804e72c405aacbe297f0e5e247c7
DIFF:
https://github.com/llvm/llvm-project/commit/4987ae84622b804e72c405aacbe297f0e5e247c7.diff
L
Author: David Green
Date: 2023-01-04T13:09:26Z
New Revision: 997852920d52442242fca9173a7b003b1164e26d
URL:
https://github.com/llvm/llvm-project/commit/997852920d52442242fca9173a7b003b1164e26d
DIFF:
https://github.com/llvm/llvm-project/commit/997852920d52442242fca9173a7b003b1164e26d.diff
LOG: [
Author: David Green
Date: 2023-01-11T08:48:23Z
New Revision: 0c0127bb9f0098752a9769748511e170ed240695
URL:
https://github.com/llvm/llvm-project/commit/0c0127bb9f0098752a9769748511e170ed240695
DIFF:
https://github.com/llvm/llvm-project/commit/0c0127bb9f0098752a9769748511e170ed240695.diff
LOG: [
Author: David Green
Date: 2023-01-11T10:10:01Z
New Revision: 1bb80214b63007784d7eab93835ebc4ac5da7b69
URL:
https://github.com/llvm/llvm-project/commit/1bb80214b63007784d7eab93835ebc4ac5da7b69
DIFF:
https://github.com/llvm/llvm-project/commit/1bb80214b63007784d7eab93835ebc4ac5da7b69.diff
LOG: [
Author: David Green
Date: 2022-11-03T15:18:36Z
New Revision: 3edd18876950693cbc69edda429f223616e3c052
URL:
https://github.com/llvm/llvm-project/commit/3edd18876950693cbc69edda429f223616e3c052
DIFF:
https://github.com/llvm/llvm-project/commit/3edd18876950693cbc69edda429f223616e3c052.diff
LOG: [
Author: David Green
Date: 2022-11-03T16:06:35Z
New Revision: e7deca525058778df15e7888ed24974a32c8686c
URL:
https://github.com/llvm/llvm-project/commit/e7deca525058778df15e7888ed24974a32c8686c
DIFF:
https://github.com/llvm/llvm-project/commit/e7deca525058778df15e7888ed24974a32c8686c.diff
LOG: [
Author: David Green
Date: 2022-11-08T19:30:26Z
New Revision: f0e6c403c2d399e4fd821aa5a7e4a20534494c71
URL:
https://github.com/llvm/llvm-project/commit/f0e6c403c2d399e4fd821aa5a7e4a20534494c71
DIFF:
https://github.com/llvm/llvm-project/commit/f0e6c403c2d399e4fd821aa5a7e4a20534494c71.diff
LOG: [
Author: David Green
Date: 2023-01-30T16:05:25Z
New Revision: 8f6c623e874624c1f247f93bf457d5196a84cec6
URL:
https://github.com/llvm/llvm-project/commit/8f6c623e874624c1f247f93bf457d5196a84cec6
DIFF:
https://github.com/llvm/llvm-project/commit/8f6c623e874624c1f247f93bf457d5196a84cec6.diff
LOG: [
Author: David Green
Date: 2023-01-31T19:17:22Z
New Revision: 00ce96b02e87c1ceba1857590f56c647ad91db91
URL:
https://github.com/llvm/llvm-project/commit/00ce96b02e87c1ceba1857590f56c647ad91db91
DIFF:
https://github.com/llvm/llvm-project/commit/00ce96b02e87c1ceba1857590f56c647ad91db91.diff
LOG: [
Author: David Green
Date: 2023-02-01T09:21:07Z
New Revision: f559e781b2bd918d8cac8a878639870a8f26196d
URL:
https://github.com/llvm/llvm-project/commit/f559e781b2bd918d8cac8a878639870a8f26196d
DIFF:
https://github.com/llvm/llvm-project/commit/f559e781b2bd918d8cac8a878639870a8f26196d.diff
LOG: [
Author: David Green
Date: 2023-01-12T18:21:28Z
New Revision: 753aca0a3ab0c1822ab3a95beaf8eaa91d7a157d
URL:
https://github.com/llvm/llvm-project/commit/753aca0a3ab0c1822ab3a95beaf8eaa91d7a157d
DIFF:
https://github.com/llvm/llvm-project/commit/753aca0a3ab0c1822ab3a95beaf8eaa91d7a157d.diff
LOG: [
Author: David Green
Date: 2023-01-16T16:58:18Z
New Revision: 0f422215ac63da4cb610a21998a2d24c11703fbf
URL:
https://github.com/llvm/llvm-project/commit/0f422215ac63da4cb610a21998a2d24c11703fbf
DIFF:
https://github.com/llvm/llvm-project/commit/0f422215ac63da4cb610a21998a2d24c11703fbf.diff
LOG: [
Author: David Green
Date: 2023-01-19T15:37:50Z
New Revision: ee700dec052a0336798fb2570faec31719b53f8d
URL:
https://github.com/llvm/llvm-project/commit/ee700dec052a0336798fb2570faec31719b53f8d
DIFF:
https://github.com/llvm/llvm-project/commit/ee700dec052a0336798fb2570faec31719b53f8d.diff
LOG: [
Author: David Green
Date: 2023-01-23T18:39:17Z
New Revision: cc9fa501ea668d197c8b55da17b76680fe79b231
URL:
https://github.com/llvm/llvm-project/commit/cc9fa501ea668d197c8b55da17b76680fe79b231
DIFF:
https://github.com/llvm/llvm-project/commit/cc9fa501ea668d197c8b55da17b76680fe79b231.diff
LOG: [
davemgreen wrote:
The test case you have is testing different lanes from the vcmla instrinsics,
not just commutativity. The different lanes would be expected to be different.
The lane indices would need to be the same to test commutivity:
```
vst1q_lane_f64(r0, test_rot0(acc, lhs, rhs) , 0);
https://github.com/davemgreen commented:
Could this use __builtin_roundeven directly, avoiding the need for
__builtin_arm_rintnf?
https://github.com/llvm/llvm-project/pull/66112
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
https://github.com/davemgreen approved this pull request.
Thanks. LGTM
https://github.com/llvm/llvm-project/pull/66112
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -194,8 +194,23 @@ entry:
ret <8 x i8> %vrshrn_n2
}
-declare <8 x i8> @llvm.aarch64.neon.rshrn.v8i8(<8 x i16>, i32)
+define dso_local <8 x i16> @uaddlv_dup_v8i16(<8 x i16> %a) {
+; CHECK-LABEL: uaddlv_dup_v8i16:
+; CHECK: // %bb.0: // %entry
+; CHECK-NEXT:uaddlv
@@ -194,8 +194,23 @@ entry:
ret <8 x i8> %vrshrn_n2
}
-declare <8 x i8> @llvm.aarch64.neon.rshrn.v8i8(<8 x i16>, i32)
+define dso_local <8 x i16> @uaddlv_dup_v8i16(<8 x i16> %a) {
+; CHECK-LABEL: uaddlv_dup_v8i16:
+; CHECK: // %bb.0: // %entry
+; CHECK-NEXT:uaddlv
@@ -6077,6 +6077,8 @@ defm : DUPWithTruncPats;
defm : DUPWithTruncPats;
defm : DUPWithTruncPats;
+defm : DUPWithTruncPats;
davemgreen wrote:
There isn't really an trunc going on here, If I'm understanding what is going
on. Can we add a DAG combine for
```
@@ -194,8 +194,23 @@ entry:
ret <8 x i8> %vrshrn_n2
}
-declare <8 x i8> @llvm.aarch64.neon.rshrn.v8i8(<8 x i16>, i32)
+define dso_local <8 x i16> @uaddlv_dup_v8i16(<8 x i16> %a) {
+; CHECK-LABEL: uaddlv_dup_v8i16:
+; CHECK: // %bb.0: // %entry
+; CHECK-NEXT:uaddlv
@@ -5329,7 +5329,8 @@ SDValue
AArch64TargetLowering::LowerINTRINSIC_WO_CHAIN(SDValue Op,
case Intrinsic::aarch64_neon_uaddlv: {
EVT OpVT = Op.getOperand(1).getValueType();
EVT ResVT = Op.getValueType();
-if (ResVT == MVT::i32 && (OpVT == MVT::v8i8 || OpVT == MVT:
@@ -194,8 +194,23 @@ entry:
ret <8 x i8> %vrshrn_n2
}
-declare <8 x i8> @llvm.aarch64.neon.rshrn.v8i8(<8 x i16>, i32)
+define dso_local <8 x i16> @uaddlv_dup_v8i16(<8 x i16> %a) {
+; CHECK-LABEL: uaddlv_dup_v8i16:
+; CHECK: // %bb.0: // %entry
+; CHECK-NEXT:uaddlv
https://github.com/davemgreen review_requested
https://github.com/llvm/llvm-project/pull/65423
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: David Green
Date: 2019-11-27T13:32:29Z
New Revision: 9f15fcc2718f95f1dac9e6e57aa93d84e9709930
URL:
https://github.com/llvm/llvm-project/commit/9f15fcc2718f95f1dac9e6e57aa93d84e9709930
DIFF:
https://github.com/llvm/llvm-project/commit/9f15fcc2718f95f1dac9e6e57aa93d84e9709930.diff
LOG: [
Author: David Green
Date: 2019-12-02T19:30:54Z
New Revision: 1d4587346f51ca5cc5741337cadfaeb208ca59ad
URL:
https://github.com/llvm/llvm-project/commit/1d4587346f51ca5cc5741337cadfaeb208ca59ad
DIFF:
https://github.com/llvm/llvm-project/commit/1d4587346f51ca5cc5741337cadfaeb208ca59ad.diff
LOG: [
Author: David Green
Date: 2019-12-09T12:50:05Z
New Revision: f7e7a5f1b6dd318d39627445c6a9ca7568d8cd61
URL:
https://github.com/llvm/llvm-project/commit/f7e7a5f1b6dd318d39627445c6a9ca7568d8cd61
DIFF:
https://github.com/llvm/llvm-project/commit/f7e7a5f1b6dd318d39627445c6a9ca7568d8cd61.diff
LOG: [
Author: David Green
Date: 2023-03-30T16:46:47+01:00
New Revision: 43aa293aeaf04e8da50c3c53169c0311e0c5
URL:
https://github.com/llvm/llvm-project/commit/43aa293aeaf04e8da50c3c53169c0311e0c5
DIFF:
https://github.com/llvm/llvm-project/commit/43aa293aeaf04e8da50c3c53169c0311e0c5.diff
L
Author: dmgreen
Date: Fri Mar 17 10:38:49 2017
New Revision: 298097
URL: http://llvm.org/viewvc/llvm-project?rev=298097&view=rev
Log:
Test commit.
Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/ARM.h
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/ARM.h
URL:
http://llvm.org/viewvc/llvm-proje
davemgreen wrote:
Hi - I like the change. We have this code in the downstream compiler, which
also enables this for Armv6, but specifically disables it for v6m and
v8m.baseline.
```
if (VersionNum < 6 ||
Triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArch_v6m ||
@@ -895,19 +895,17 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
// defaults this bit to 0 and handles it as a system-wide (not
// per-process) setting. It is therefore safe to assume that ARMv7+
// Linux targets support unaligned accesses. The s
https://github.com/davemgreen commented:
> Unaligned accesses require that SCTLR.A is 0, SCTLR.U is 1, and that the
> memory in question is configured as "normal" memory. Almost all operating
> systems do in fact configure their registers/memory this way, but on
> baremetal it's not really a s
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/82400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -22,6 +22,12 @@
// RUN: %clang -target armv7-windows -### %s 2> %t
// RUN: FileCheck --check-prefix=CHECK-UNALIGNED-ARM < %t %s
+// RUN: %clang --target=armv6 -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-ALIGNED-ARM < %t %s
+
+// RUN: %clang --target=armv7 -### %s
@@ -305,6 +305,17 @@ X86 Support
Arm and AArch64 Support
^^^
+- ARMv7+ targets now default to allowing unaligned access, except Armv6-M, and
+ Armv8-M without the Main Extension. Baremetal targets should check that the
+ new default will work with their s
davemgreen wrote:
I would also personally add Armv6 too for consistency, but don't have a strong
opinion.
https://github.com/llvm/llvm-project/pull/82400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
davemgreen wrote:
Hi this sounds like a good idea to me. Note that the implementation of
getHostCPUFeatures isn't amazing for AArch64 at the moment, there was an
attempt to fix it up in #95694 (but thaat has gone a bit quiet). One point we
noticed is that it could end up turning "aes+sha2" int
davemgreen wrote:
AArch64 has a udot and sdot instruction (and a usdot instruction). They perform
a "partial" reduction though, producing a v4i32 from two v16i8 inputs. We would
like to use those from the vectorizer and have recently added a
partial-reduction intrinsic, but doing it with a hig
https://github.com/davemgreen commented:
I'm not sure if we have any experimental __builtin's, but it sounds OK to me.
If we do add this, do we need to make sure all lowering works? (For all the SVE
types).
https://github.com/llvm/llvm-project/pull/102476
___
davemgreen wrote:
> Cortex-A710 does not appear to have SSBS
It would be very surprising to drop it from one generation of cpus, only to add
it again in the next!
I believe this says it should be present:
https://developer.arm.com/documentation/101800/0201/AArch64-registers/AArch64-Identificat
https://github.com/davemgreen commented:
> LGTM. The main change to point out is that the target attribute will no
> longer accept internal feature names. I don't think it should ever have done
> so, but we should get input from others. @davemgreen? There are references to
> existing code in [
davemgreen wrote:
Yeah I had just seen that error message before you edited your comment. There
are some examples of neon I found in a quick search, which were presumably
added for AArch32:
https://github.com/aaru-dps/Aaru.Checksums.Native/blob/bd5051ce181b225a7662bfb764ebcc5cbe7542b2/simd.h#L1
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/94633
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen approved this pull request.
LGTM, thanks
https://github.com/llvm/llvm-project/pull/94633
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -90,6 +90,8 @@ def ProcR7 : SubtargetFeature<"r7", "ARMProcFamily",
"CortexR7",
"Cortex-R7 ARM processors", []>;
def ProcR52 : SubtargetFeature<"r52", "ARMProcFamily", "CortexR52",
"Cortex-R52 AR
@@ -1,4 +1,5 @@
; RUN: llc < %s -mtriple=armv8r-eabi -mcpu=cortex-r52 | FileCheck %s
--check-prefix=CHECK --check-prefix=USEAA
+; RUN: llc < %s -mtriple=armv8r-eabi -mcpu=cortex-r52plus | FileCheck %s
--check-prefix=CHECK --check-prefix=USEAA
davemgreen wrote:
@@ -723,6 +746,9 @@ def ProcessorFeatures {
FeaturePerfMon, FeatureETE, FeatureTRBE,
FeatureSPE, FeatureMTE, FeatureSVE2BitPerm,
FeatureFP16FML, FeatureSPE_EEF];
+ list X925 = [H
https://github.com/davemgreen approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/95214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
davemgreen wrote:
If you remove tan from isTriviallyVectorizable it should prevent vectorization
in the short term.
It might be better to default FTAN to expand in
https://github.com/llvm/llvm-project/blob/64c9a1e1266ec7bc4c4896b2df116fa12dbacf15/llvm/lib/CodeGen/TargetLoweringBase.cpp#L960,
davemgreen wrote:
Usually when new ISD nodes are added they are expanded for all types, so that
every backend will get at least working code even if it is not optimal. The
targets can then come along and override the defaults for the types they are
interested in, to get better results.
For ta
davemgreen wrote:
I believe they were added so long ago that the default Expanding wasn't done at
the time. @efriedma-quic do you have more of an idea than that?
https://github.com/llvm/llvm-project/pull/94559
___
cfe-commits mailing list
cfe-commits@
@@ -19,3 +19,19 @@
// RUN: %clang --target=arm64 -mlittle-endian -march=armv8.1a -### -c %s 2>&1
| FileCheck -check-prefix=ARM64-GENERICV81A %s
// RUN: %clang --target=arm64 -mlittle-endian -march=armv8.1-a -### -c %s 2>&1
| FileCheck -check-prefix=ARM64-GENERICV81A %s
// ARM
@@ -140,89 +152,480 @@ def FeatureAES : Extension<
// compatibility, and now imply features SHA2 and AES, which was the
// "traditional" meaning of Crypto.
let FMVDependencies = "+aes,+sha2" in
-def FeatureCrypto : Extension<"crypto", "Crypto",
+def FeatureCrypto : ExtensionWit
@@ -19,3 +19,19 @@
// RUN: %clang --target=arm64 -mlittle-endian -march=armv8.1a -### -c %s 2>&1
| FileCheck -check-prefix=ARM64-GENERICV81A %s
// RUN: %clang --target=arm64 -mlittle-endian -march=armv8.1-a -### -c %s 2>&1
| FileCheck -check-prefix=ARM64-GENERICV81A %s
// ARM
Author: David Green
Date: 2024-06-21T09:26:44+01:00
New Revision: b635d690ed1e3fbebab9dee1b157fa380d3e9eba
URL:
https://github.com/llvm/llvm-project/commit/b635d690ed1e3fbebab9dee1b157fa380d3e9eba
DIFF:
https://github.com/llvm/llvm-project/commit/b635d690ed1e3fbebab9dee1b157fa380d3e9eba.diff
L
@@ -877,6 +905,8 @@ def : ProcessorModel<"cortex-x3", NeoverseN2Model,
ProcessorFeatures.X3,
[TuneX3]>;
def : ProcessorModel<"cortex-x4", NeoverseN2Model, ProcessorFeatures.X4,
[TuneX4]>;
+def : ProcessorModel<"cortex-x925", NeoverseN2
@@ -863,6 +889,8 @@ def : ProcessorModel<"cortex-a720", NeoverseN2Model,
ProcessorFeatures.A720,
[TuneA720]>;
def : ProcessorModel<"cortex-a720ae", NeoverseN2Model,
ProcessorFeatures.A720AE,
[TuneA720AE]>;
+def : ProcessorModel<"corte
davemgreen wrote:
Does this disable neon by default for cortex-r52? If so I don't think it should
be doing that, it would be a break in the existing behaviour, and should at
least be in the release notes.
The general rule for -mcpu options is that they should (roughly) enable the
maximum set
davemgreen wrote:
As far as I understand this will remove the tuning we do for cortex-r52 when
using armv8r, which will mean a little less performance but the tuning features
in the Arm backend are not handled as well as they could be.
Can you add release note explaining what will change? Than
davemgreen wrote:
It is that bit of code, yeah. I don't know of a way to reproduce this without
logging into different machines with different sets of options and trying it.
If we had a way to test/mock that various /proc/cpuinfo files gave us the
correct results, that would be helpful in givi
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/98196
>From b46d892a43b034dd515987f37441fc842710dc62 Mon Sep 17 00:00:00 2001
From: Haowei Wu
Date: Wed, 31 Jul 2024 12:12:26 +0100
Subject: [PATCH] Revert "[C++20] [Modules] Always emit the inline builtins"
This r
https://github.com/davemgreen commented:
Did you consider emitting `llvm.fmin(llvm.fabs(x), llvm.fabs(y))`?
https://github.com/llvm/llvm-project/pull/99041
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
davemgreen wrote:
I'm not sure I would make this change, mostly due to it potentially causing a
break for existing users and making performance worse, but can see the
reasoning. I am willing to defer to others if they have an opinion.
https://github.com/llvm/llvm-project/pull/88287
___
@@ -447,6 +447,16 @@ def TuneNeoverseN2 : SubtargetFeature<"neoversen2",
"ARMProcFamily", "NeoverseN2
FeatureEnableSelectOptimize,
FeaturePredictableSelectIsExpensive]>;
+def TuneNeoverseN3 : Subtarge
https://github.com/davemgreen approved this pull request.
Thanks. I didn't check the enabled features but the tunings look good to me.
https://github.com/llvm/llvm-project/pull/90143
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
@@ -632,7 +632,18 @@ inline constexpr CpuInfo CpuInfos[] = {
AArch64::AEK_PAUTH, AArch64::AEK_SVE2BITPERM,
AArch64::AEK_FLAGM, AArch64::AEK_PERFMON,
AArch64::AEK_PREDRES, AArch64::AEK_P
@@ -143,6 +143,7 @@ void AArch64Subtarget::initializeProperties(bool
HasMinSize) {
case CortexA78AE:
case CortexA78C:
case CortexR82:
+ case CortexR82AE:
davemgreen wrote:
Can you move both of these into the block with CortexA55? It has always been in
@@ -632,7 +632,18 @@ inline constexpr CpuInfo CpuInfos[] = {
AArch64::AEK_PAUTH, AArch64::AEK_SVE2BITPERM,
AArch64::AEK_FLAGM, AArch64::AEK_PERFMON,
AArch64::AEK_PREDRES, AArch64::AEK_P
https://github.com/davemgreen approved this pull request.
Thanks. LGTM
https://github.com/llvm/llvm-project/pull/90440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -380,6 +380,9 @@ ARM_CPU_NAME("neoverse-n1", ARMV8_2A,
FK_CRYPTO_NEON_FP_ARMV8, false,
ARM_CPU_NAME("neoverse-n2", ARMV9A, FK_NEON_FP_ARMV8, false,
(ARM::AEK_BF16 | ARM::AEK_DOTPROD | ARM::AEK_FP16FML |
ARM::AEK_I8MM | ARM::AEK_RAS | ARM::AEK_SB )
davemgreen wrote:
Hi - We've ran into a couple of places where this causes problems, one of them
in running Spec as above. Is it possible to turn off this error for older
codebases with a flag, turning it into a warning? It doesn't seem like a very
useful error if it applies to code that is ne
davemgreen wrote:
IMO This patch looks far too large to sensibly review and needs to be split up.
A lot of the changes don't really looks like mechanical renamings, and it is
hard to see how they would not break existing uses of llvm arch64 target
features?
https://github.com/llvm/llvm-projec
davemgreen wrote:
> This is already split into 18 commits, I don't think there's any reason to
> split it into 18 PRs, since comments on one of them likely apply to the
> others.
I disagree. This is going to be awkward for a lot of users of llvm and contains
at least some details I don't agre
davemgreen wrote:
> which change? Specifying -mcpu=cortex-r52 will behave the same way as before.
> The original manual for the R52 provided for a no-neon sp-only variant, and
> they exist in the wild, and this lets "architecture-generic" builds
> automatically support both.
I just meant the
davemgreen wrote:
@tmatheson-arm reached out and we have a bit of a conversation internally. I do
think that there is too much going on in this one pr to be sensible to review,
but from what I've looked at my main points I think are:
- Some AEK names get renamed in ways I would not expect them
davemgreen wrote:
Rust
(https://github.com/rust-lang/rust/blob/79734f1db8dbe322192dea32c0f6b80ab14c4c1d/compiler/rustc_codegen_llvm/src/llvm_util.rs#L229)
and zig
(https://github.com/ziglang/zig/blob/44db92d1ca90c9cfdfb29fe46f04ff8f11c80901/lib/std/Target/aarch64.zig#L43)
are two examples of
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/91854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen commented:
The Arm/AArch64 tests looks OK for the most part. I might be able to help with
some of them if that is easier than trying to sort them all here.
https://github.com/llvm/llvm-project/pull/91854
___
cfe-commits m
@@ -22,7 +22,7 @@ define signext i8 @test1(i32 %A) {
; CHECK-V7: @ %bb.0:
; CHECK-V7-NEXT:sbfx r0, r0, #8, #8
; CHECK-V7-NEXT:bx lr
-; CHECk-V7: sbfx r0, r0, #8, #8
+; CHECK-V7: sbfx r0, r0, #8, #8
davemgreen wrote:
I believe we can delete this l
@@ -217,42 +217,42 @@ define <4 x i32> @load_v3i8_to_4xi32_const_offset_3(ptr
%src) {
}
define <4 x i32> @volatile_load_v3i8_to_4xi32(ptr %src) {
-; check-label: volatile_load_v3i8_to_4xi32:
+; check-LABEL: volatile_load_v3i8_to_4xi32:
davemgreen wrote:
I th
@@ -189,15 +189,15 @@ define i32 @shr(i32 %a, i32 %b) {
define i1 @outer_and1(i1 %a) {
-; check-label: @outer_and1(
-; check-not: call i1 @and1
+; check-LABEL: @outer_and1(
davemgreen wrote:
Should all these be "CHECK"?
https://github.com/llvm/llvm-project/
@@ -121,7 +121,7 @@ define i32 @test_orr_extract_from_mul_1(i32 %x, i32 %y) {
; CHECK-THUMB-NEXT:orrs r0, r1
; CHECK-THUMB-NEXT:bx lr
entry:
-; CHECk-THUMB: orrs r0, r1
davemgreen wrote:
I believe we can delete this line, it was left in from the old ch
@@ -189,15 +189,15 @@ define i32 @shr(i32 %a, i32 %b) {
define i1 @outer_and1(i1 %a) {
-; check-label: @outer_and1(
-; check-not: call i1 @and1
+; check-LABEL: @outer_and1(
davemgreen wrote:
I've regenerated the check lines in 220756f1f92b335cbafdff67c570d09
Author: David Green
Date: 2022-01-27T18:43:06Z
New Revision: 1fec2154b29f84b53dd578b9f87f34e255630771
URL:
https://github.com/llvm/llvm-project/commit/1fec2154b29f84b53dd578b9f87f34e255630771
DIFF:
https://github.com/llvm/llvm-project/commit/1fec2154b29f84b53dd578b9f87f34e255630771.diff
LOG: [
Author: David Green
Date: 2022-01-11T12:33:53Z
New Revision: 0c7f515f88fca39458f3b3fd9db188e48db0a7e4
URL:
https://github.com/llvm/llvm-project/commit/0c7f515f88fca39458f3b3fd9db188e48db0a7e4
DIFF:
https://github.com/llvm/llvm-project/commit/0c7f515f88fca39458f3b3fd9db188e48db0a7e4.diff
LOG: R
davemgreen wrote:
Could you explain more about what broke? Are you using target(..) attributes?
https://github.com/llvm/llvm-project/pull/96832
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
@@ -2096,3 +2096,19 @@ let ArchGuard = "defined(__aarch64__) ||
defined(__arm64ec__)", TargetGuard = "r
def VLDAP1_LANE : WInst<"vldap1_lane", ".(c*!).I", "QUlQlUlldQdPlQPl">;
def VSTL1_LANE : WInst<"vstl1_lane", "v*(.!)I", "QUlQlUlldQdPlQPl">;
}
+
+//Lookup table read wi
@@ -6420,6 +6420,76 @@ def : Pat<(v16i8 (int_aarch64_neon_tbx1 (v16i8 V128:$Rd),
let Predicates = [HasLUT] in {
defm LUT2 : BaseSIMDTableLookupIndexed2<"luti2">;
defm LUT4 : BaseSIMDTableLookupIndexed4<"luti4">;
+
+ def : Pat<(v16i8 (int_aarch64_neon_vluti2_lane (v8i8 V64:
https://github.com/davemgreen commented:
Thanks this looks great. I've not checked the C / ACLE intrinsics though - I
will defer to @CarolineConcatto and @momchil-velikov for those parts if that is
OK.
https://github.com/llvm/llvm-project/pull/96883
https://github.com/davemgreen commented:
I think this is OK but do you know if the dsp side works with cortex-m? Target
attributes are less likely to be used there, but it's worth testing if the
command line args are still all happy.
https://github.com/llvm/llvm-project/pull/107417
___
@@ -1159,7 +1159,9 @@ class ARMOperand : public MCParsedAsmOperand {
if (!isImm()) return false;
const MCConstantExpr *CE = dyn_cast(getImm());
if (!CE) return false;
davemgreen wrote:
Can this check that CE->getActiveBits() > 32?
https://github.c
@@ -70,6 +70,10 @@ static std::unique_ptr
LLVM_ATTRIBUTE_UNUSED getProcCpuinfoContent() {
llvm::ErrorOr> Text =
llvm::MemoryBuffer::getFileAsStream("/proc/cpuinfo");
+ if (const char *cpuinfoIntercept = std::getenv("LLVM_CPUINFO")) {
+Text = llvm::MemoryBuffer:
@@ -70,6 +70,10 @@ static std::unique_ptr
LLVM_ATTRIBUTE_UNUSED getProcCpuinfoContent() {
llvm::ErrorOr> Text =
llvm::MemoryBuffer::getFileAsStream("/proc/cpuinfo");
+ if (const char *cpuinfoIntercept = std::getenv("LLVM_CPUINFO")) {
davemgreen wro
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/97749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen commented:
Thanks for adding the tests. They look like a useful addition.
https://github.com/llvm/llvm-project/pull/97749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
davemgreen wrote:
It looks like there is already a warning for this in clang, it only triggers
from -mfloat-abi=hard though: https://godbolt.org/z/dcaz8had4. Could it be made
to work with any hard-float env? And maybe be made an error down-gradable to a
warning?
Generally clang-level warnings
101 - 200 of 335 matches
Mail list logo
