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
@@ -633,6 +633,13 @@ Lnovec:
.arch_extension gcs
#endif
+#if defined(__ARM_FP) && __ARM_FP != 0
+#define LDP(a,b,r,o,p) stp a, b, [r, o]
+#else
+/* In reverse order so that the last LDP(x0,x1,x0) works. */
+#define LDP(a,b,r,o,p) ldr b, [r, p] ; ldr a, [r, o]
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/110825
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -118,9 +118,9 @@ struct ArchInfo {
// Defines the following partial order, indicating when an architecture is
// a superset of another:
//
- // v9.5a > v9.4a > v9.3a > v9.2a > v9.1a > v9a;
- // v v v v v
- // v8.9a > v
https://github.com/davemgreen approved this pull request.
This LGTM if there are no other comments.
https://github.com/llvm/llvm-project/pull/110825
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
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
___
@@ -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:
> 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:
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:
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 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
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 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:
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
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
@@ -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:
@@ -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
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-
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
@@ -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
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@
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:
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,
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
@@ -723,6 +746,9 @@ def ProcessorFeatures {
FeaturePerfMon, FeatureETE, FeatureTRBE,
FeatureSPE, FeatureMTE, FeatureSVE2BitPerm,
FeatureFP16FML, FeatureSPE_EEF];
+ list X925 = [H
@@ -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:
@@ -90,6 +90,8 @@ def ProcR7 : SubtargetFeature<"r7", "ARMProcFamily",
"CortexR7",
"Cortex-R7 ARM processors", []>;
def ProcR52 : SubtargetFeature<"r52", "ARMProcFamily", "CortexR52",
"Cortex-R52 AR
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
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
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 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 [
@@ -863,6 +889,8 @@ def : ProcessorModel<"cortex-a720", NeoverseN2Model,
ProcessorFeatures.A720,
[TuneA720]>;
def : ProcessorModel<"cortex-a720ae", NeoverseN2Model,
ProcessorFeatures.A720AE,
[TuneA720AE]>;
+def : ProcessorModel<"corte
@@ -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
@@ -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
@@ -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:
Should all these be "CHECK"?
https://github.com/llvm/llvm-project/
@@ -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
@@ -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
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
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
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
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:
> 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:
> 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:
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:
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
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
@@ -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. 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
@@ -447,6 +447,16 @@ def TuneNeoverseN2 : SubtargetFeature<"neoversen2",
"ARMProcFamily", "NeoverseN2
FeatureEnableSelectOptimize,
FeaturePredictableSelectIsExpensive]>;
+def TuneNeoverseN3 : Subtarge
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
___
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:
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
https://github.com/davemgreen approved this pull request.
Thanks. LGTM
https://github.com/llvm/llvm-project/pull/85401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -58,6 +58,7 @@ class AArch64Subtarget final : public AArch64GenSubtargetInfo
{
CortexA55,
CortexA510,
CortexA520,
+CortexA520AE,
davemgreen wrote:
These might not be worth adding, considering they should be the same as
CortexA520, and coul
@@ -67,6 +67,8 @@ Changes to Interprocedural Optimizations
Changes to the AArch64 Backend
--
+* Added support for Cortex-A520AE and Cortex-A720AE CPUs.
davemgreen wrote:
Could this have Cortex-A78AE too?
https://github.com/llvm/ll
https://github.com/davemgreen commented:
Hi - I think this looks sensible, considering that long double == fp128. Should
we be doing the same for other OS's in this file too?
https://github.com/llvm/llvm-project/pull/85070
___
cfe-commits mailing lis
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
@@ -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
@@ -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
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
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
@@ -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
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 ||
davemgreen wrote:
I'm a little worried people might be relying on the existing behaviour, with
both clang and GCC having this wrong for a while. If we are going to do it can
you add a release note to clang explaining the new behaviour?
https://github.com/llvm/llvm-project/pull/81493
__
@@ -201,17 +201,27 @@ define dso_local void @rv_marker_3() personality ptr
@__gxx_personality_v0 {
; GISEL-NEXT:bl _objc_object
; GISEL-NEXT: Ltmp1:
; GISEL-NEXT: ; %bb.1: ; %invoke.cont
-; GISEL-NEXT:ldp x29, x30, [sp, #16] ; 16-byte Folded Reload
+; GISEL-NEXT: Ll
davemgreen wrote:
I think this is probably OK for Arm & AArch64. In the long run we should
ideally be adding better extract subvector costs, but this patch moves the cost
in that direction.
https://github.com/llvm/llvm-project/pull/79837
___
cfe-comm
davemgreen wrote:
I see. The issue is that the opposite is often true as well - if we add a
target specific intrinsic for this then, whilst we get a single instruction
being emitted, we don't see all the other optimizations that the compiler can
and should be performing.
Things like constant
https://github.com/davemgreen approved this pull request.
Thanks. LGTM too.
https://github.com/llvm/llvm-project/pull/79614
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
davemgreen wrote:
OK. We would not usually add intrinsics like this without a strong motivating
case, that could not be optimized in some other way. It is better to use target
independent options when available, and inline assembly is available as a
fallback if it is really needed. But I would
davemgreen wrote:
Hello. Can you explain why this is needed, as opposed to using the equivalent
shift/and/ors?
https://github.com/llvm/llvm-project/pull/79672
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
davemgreen wrote:
It looks like this needs to update testAArch64CPUArchList too. Otherwise it LGTM
https://github.com/llvm/llvm-project/pull/79614
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
https://github.com/davemgreen approved this pull request.
https://github.com/ARM-software/acle/pull/279 was committed recently, where I
think this lines up with the final version of it. I think this LGTM in that
case.
https://github.com/llvm/llvm-project/pull/75516
https://github.com/davemgreen approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/77555
___
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.
Thanks. LGTM
https://github.com/llvm/llvm-project/pull/75440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/davemgreen approved this pull request.
Thanks for the updates. From what I can tell this LGTM, but it will need a
rebase.
You might want to commit it with the option disabled, and then flip the switch
in a followup to avoid the commit-revert cycles in case there are any issu
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/72273
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
davemgreen wrote:
If you can make armv9-a work the same as armv8-a and add some tests for it then
this LGTM
https://github.com/llvm/llvm-project/pull/75440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
@@ -836,6 +837,70 @@ void ARMTargetInfo::getTargetDefines(const LangOptions
&Opts,
if (Opts.RWPI)
Builder.defineMacro("__ARM_RWPI", "1");
+ // Macros for enabling co-proc intrinsics
+ uint64_t FeatureCoprocBF = 0;
+ switch (ArchKind) {
+ default:
+break;
+ case
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/75440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -756,6 +756,58 @@ __arm_st64bv0(void *__addr, data512_t __value) {
__builtin_arm_mops_memset_tag(__tagged_address, __value, __size)
#endif
+/* Coprocessor Intrinsics */
+#if defined(__ARM_FEATURE_COPROC)
+
+#if (__ARM_FEATURE_COPROC & 0x1)
+
+#if (__ARM_ARCH != 8)
---
@@ -836,6 +837,70 @@ void ARMTargetInfo::getTargetDefines(const LangOptions
&Opts,
if (Opts.RWPI)
Builder.defineMacro("__ARM_RWPI", "1");
+ // Macros for enabling co-proc intrinsics
+ uint64_t FeatureCoprocBF = 0;
+ switch (ArchKind) {
+ default:
+break;
+ case
@@ -836,6 +837,70 @@ void ARMTargetInfo::getTargetDefines(const LangOptions
&Opts,
if (Opts.RWPI)
Builder.defineMacro("__ARM_RWPI", "1");
+ // Macros for enabling co-proc intrinsics
+ uint64_t FeatureCoprocBF = 0;
+ switch (ArchKind) {
+ default:
+break;
+ case
https://github.com/davemgreen commented:
Thanks. This is looking good to me. I just have a few comments about different
architecture revisions.
https://github.com/llvm/llvm-project/pull/75440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
davemgreen wrote:
Thanks for doing this.
I think that __ARM_FEATURE_COPROC should be a bitfield, as defined in
https://arm-software.github.io/acle/main/acle.html#coprocessor-intrinsics. That
would remove the need for the other macros.
https://github.com/llvm/llvm-project/pull/75440
___
davemgreen wrote:
This is the downstream code we have:
https://gist.github.com/davemgreen/e7ade833274a60e975e67a66eda7cb44
Note that the __ARM_TARGET_COPROC_XYZ macros are probably wrong. They should be
__ARM_FEATURE_COPROC bitfield macros according to the ACLE.
Can you make use of some of tha
davemgreen wrote:
Let me try and get the downstream version, you might be able to pick up some
things from it. A test at least should probably be present.
https://github.com/llvm/llvm-project/pull/75440
___
cfe-commits mailing list
cfe-commits@lists.l
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,816 @@
+//===- AArch64LoopIdiomTransform.cpp - Loop idiom recognition
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
1 - 100 of 199 matches
Mail list logo
