@@ -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 closed
https://github.com/llvm/llvm-project/pull/110085
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
davemgreen wrote:
> Hi David, rebase done. Could you help to merge?
Thanks - it looks like the errors were unrelated - something that was broken on
trunk earlier. Please yell if it does look like something is going wrong.
https://github.com/llvm/llvm-project/pull/110085
___
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 approved this pull request.
Thanks - LGTM
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
@@ -0,0 +1,137 @@
+// RUN: export LLVM_CPUINFO=%S/Inputs/cpunative/neoverse-v2
+// RUN: %clang --target=aarch64 --print-enabled-extensions -mcpu=native |
FileCheck --strict-whitespace --check-prefix=CHECK-FEAT-NV2
--implicit-check-not=FEAT_ %s
+
davemgreen wrote
davemgreen wrote:
This patch should help with the performance in other ways than the motivating
case from #113686 (the creating of fmin/fmax is one of them). Those could
probably be fixed in other ways, and my understanding was that there was a long
term goal to move away form the function lev
davemgreen wrote:
It sounds OK so lang as we can make sure the backend patterns keep working - it
sounds like it would be more resilient overall if we matched both forms. I
think it was just assumed in the past that is wasn't needed.
https://github.com/llvm/llvm-project/pull/113212
___
https://github.com/davemgreen commented:
I have always expected shuffles to be canonicalized to make the lowest mask
lane the first operand. I believe the AArch64 and Arm matching functions rely
on that at the moment. https://godbolt.org/z/1rr1E8v1K
https://github.com/llvm/llvm-project/pull/11
davemgreen wrote:
I'm not sure I understood the original error properly but if we can come up
with a fix like this it sounds sensible to me. Is the test still failing in the
pre-commit tests? You might need something stronger - like only running the
test on aarch64 host machines. There are som
davemgreen wrote:
> You could also create an ARM/ directory, and move arm-* files into that too
> (186 files)
Yeah - We might just need to be careful of tests that test both arm and aarch64
targets.
I noticed there are some arm64-* tests too that could be moved into the aarch64
directory.
ht
https://github.com/davemgreen approved this pull request.
Thanks that does look like it did it.
https://github.com/llvm/llvm-project/pull/115467
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
https://github.com/davemgreen approved this pull request.
Sounds like a good idea to me if no-one else objects. LGTM
https://github.com/llvm/llvm-project/pull/115818
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
davemgreen wrote:
You have to go searching in the test output for the aarch64-mcpu-native.c test.
The bots run clang tests separately to llvm, with a lot of verbose output,
which means the test that is failing might not be at the end of the output. It
looks like it still has the same error mes
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
@@ -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 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
davemgreen wrote:
Could you give more details about why you would want these added? As far as I
understand they are mandatory features for 8.4 and 8.7, and would usually be
added via -march=armv8.4-a for example. We try to keep the options between GCC
and clang the same, and GCC doesn't seem t
@@ -118,6 +118,8 @@ def fcmp_gt: IRBuilder<"CreateFCmpOGT">;
def fcmp_ge: IRBuilder<"CreateFCmpOGE">;
def fcmp_lt: IRBuilder<"CreateFCmpOLT">;
def fcmp_le: IRBuilder<"CreateFCmpOLE">;
davemgreen wrote:
Can _le and _lt be removed now.
https://github.com/llvm/l
davemgreen wrote:
Is this causing a problem somewhere, and returning zero? I don't think I would
expect a lane index from a type that has a sizeInBits() of 0.
https://github.com/llvm/llvm-project/pull/115883
___
cfe-commits mailing list
cfe-commits@li
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/116371
___
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.
https://github.com/llvm/llvm-project/pull/116371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
davemgreen wrote:
I agree but was having trouble putting it into words. I don't have a reference
I can put my hands on, but we have generally considered the llvm error messages
to be a poor substitute to those produced by clang and have often gone the
other way, converting llvm errors to clang
https://github.com/davemgreen commented:
This seems to match what we do in the backend. LGTM
> The MVE intrinsics are defined as having the same behaviour as the
> instructions which they correspond to.
(They are defined to match the instructions they correspond to inside the
current fp envir
davemgreen wrote:
> These instructions are being used in the hand-written assembly for a
> hypervisor. The hypervisor will check at runtime if the instructions are
> available on the current CPU before calling this code.
We try to coordinate between GCC and LLVM, to make sure we implement the
davemgreen wrote:
> I prefer `-mcpu=fujitsu-monaka`. I want to include `fujitsu` because
> `FUJITSU-MONAKA` is the official name.
>
> I fixed the issues related to sve2aes.
Sounds good, either sounds OK to me. LGTM
https://github.com/llvm/llvm-project/pull/118432
_
https://github.com/davemgreen approved this pull request.
https://github.com/llvm/llvm-project/pull/118432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
davemgreen wrote:
We never know who does and doesn't have commit access. Let us know if you are
happy and want us to hit submit. Thanks.
https://github.com/llvm/llvm-project/pull/118432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
davemgreen wrote:
> This patch adds instcombine to some tests that were passing
This patch sounds good, but the intent of the clang tests is that they should
not be dependant on the mid-end optimizations in llvm. At least for
fast-changing parts like instcombine, where you don't want to have t
Author: David Green
Date: 2025-01-06T16:26:41Z
New Revision: ca603d2536f039194141bf3a01e9ee7f60e37406
URL:
https://github.com/llvm/llvm-project/commit/ca603d2536f039194141bf3a01e9ee7f60e37406
DIFF:
https://github.com/llvm/llvm-project/commit/ca603d2536f039194141bf3a01e9ee7f60e37406.diff
LOG: [
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/120363
>From deaf0a754d72c2aa3777fe0ba963aa88031182c0 Mon Sep 17 00:00:00 2001
From: David Green
Date: Tue, 7 Jan 2025 13:10:16 +
Subject: [PATCH] [AArch64] Improve bcvtn2 and remove aarch64_neon_bfcvt
intrinsc
davemgreen wrote:
sroa would be ideal if it works, I know a number of test cases use it and it
shouldn't update too often.
https://github.com/llvm/llvm-project/pull/121801
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/124466
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen closed
https://github.com/llvm/llvm-project/pull/124466
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -401,7 +401,7 @@ def tblockaddress: SDNode<"ISD::TargetBlockAddress",
SDTPtrLeaf, [],
def add: SDNode<"ISD::ADD" , SDTIntBinOp ,
[SDNPCommutative, SDNPAssociative]>;
-def ptradd : SDNode<"ISD::ADD" , SDTPtrAddOp, []>;
+def
@@ -0,0 +1,451 @@
+; RUN: llc -mtriple=aarch64 -verify-machineinstrs --mattr=+cpa -O0
-global-isel=0 -fast-isel=0 %s -o - 2>&1 | FileCheck %s
--check-prefixes=CHECK-CPA-O0
+; RUN: llc -mtriple=aarch64 -verify-machineinstrs --mattr=+cpa -O3
-global-isel=0 -fast-isel=0 %s -o - 2>
https://github.com/davemgreen approved this pull request.
https://github.com/llvm/llvm-project/pull/126278
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -5025,6 +5025,11 @@ def msve_vector_bits_EQ : Joined<["-"],
"msve-vector-bits=">, Group,
HelpText<"Specify the size in bits of an SVE vector register. Defaults to
the"
" vector length agnostic value of \"scalable\". (AArch64 only)">;
+
+def mcpa_codegen : Flag<
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/124466
>From c43c26262c25ffb99ee411c05d19739d83cf1c05 Mon Sep 17 00:00:00 2001
From: David Green
Date: Sun, 26 Jan 2025 13:47:58 +
Subject: [PATCH 1/2] [AArch64] Enable vscale_range with +sme
If we have +sme bu
davemgreen wrote:
/cherry-pick 9f1c825fb62319b94ac9604f733afd59e9eb461b
https://github.com/llvm/llvm-project/pull/124466
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen milestoned
https://github.com/llvm/llvm-project/pull/124466
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen created
https://github.com/llvm/llvm-project/pull/120363
This started out as trying to combine bf16 fpround to BFCVT2 instructions, but
ended up removing the aarch64.neon.nfcvt intrinsics in favour of generating
fpround instructions directly. This simplifies the p
davemgreen wrote:
Ah - thanks. It is hopefully fixed in 6dc356d6985fc49d1b69c20cc27f6b066742144a?
https://github.com/llvm/llvm-project/pull/120363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
davemgreen wrote:
Hi - that sounds like GISel might be miss-compiling it? It doesn't support
bf16, so shouldn't be trying to use those instructions for fp16. I can try and
take a look.
https://github.com/llvm/llvm-project/pull/120363
___
cfe-commits
@@ -9053,22 +9053,19 @@ class SIMDThreeSameVectorBF16MatrixMul
let mayRaiseFPException = 1, Uses = [FPCR] in
class SIMD_BFCVTN
- : BaseSIMDMixedTwoVector<0, 0, 0b10, 0b10110, V128, V128,
+ : BaseSIMDMixedTwoVector<0, 0, 0b10, 0b10110, V128, V64,
davemgreen w
@@ -4064,31 +4072,59 @@ static Value *upgradeX86IntrinsicCall(StringRef Name,
CallBase *CI, Function *F,
static Value *upgradeAArch64IntrinsicCall(StringRef Name, CallBase *CI,
Function *F, IRBuilder<> &Builder) {
- Intrinsic::ID New
https://github.com/davemgreen created
https://github.com/llvm/llvm-project/pull/124466
If we have +sme but not +sve, we would not set vscale_range on functions. It
should be valid to apply it with the same range with just +sme, which can help
improve the performance of generated code.
>From 7
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/124466
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -708,7 +708,7 @@ AArch64TargetInfo::getVScaleRange(const LangOptions
&LangOpts) const {
return std::pair(
LangOpts.VScaleMin ? LangOpts.VScaleMin : 1, LangOpts.VScaleMax);
- if (hasFeature("sve"))
+ if (hasFeature("sve") || hasFeature("sme"))
@@ -708,7 +708,7 @@ AArch64TargetInfo::getVScaleRange(const LangOptions
&LangOpts) const {
return std::pair(
LangOpts.VScaleMin ? LangOpts.VScaleMin : 1, LangOpts.VScaleMax);
- if (hasFeature("sve"))
+ if (hasFeature("sve") || hasFeature("sme"))
davemgreen wrote:
Is it worth adding a release note, if this is altering the ABI between versions?
https://github.com/llvm/llvm-project/pull/124760
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
https://github.com/davemgreen closed
https://github.com/llvm/llvm-project/pull/120363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: David Green
Date: 2025-01-21T10:36:58Z
New Revision: 6dc356d6985fc49d1b69c20cc27f6b066742144a
URL:
https://github.com/llvm/llvm-project/commit/6dc356d6985fc49d1b69c20cc27f6b066742144a
DIFF:
https://github.com/llvm/llvm-project/commit/6dc356d6985fc49d1b69c20cc27f6b066742144a.diff
LOG: [
@@ -708,7 +708,7 @@ AArch64TargetInfo::getVScaleRange(const LangOptions
&LangOpts) const {
return std::pair(
LangOpts.VScaleMin ? LangOpts.VScaleMin : 1, LangOpts.VScaleMax);
- if (hasFeature("sve"))
+ if (hasFeature("sve") || hasFeature("sme"))
https://github.com/davemgreen closed
https://github.com/llvm/llvm-project/pull/122965
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/120363
>From ff5b62875738cc89266aeec6f0b06f4b55d30a3a Mon Sep 17 00:00:00 2001
From: David Green
Date: Wed, 15 Jan 2025 08:21:31 +
Subject: [PATCH] [AArch64] Improve bcvtn2 and remove aarch64_neon_bfcvt
intrins
davemgreen wrote:
Rebase and ping - thanks.
https://github.com/llvm/llvm-project/pull/120363
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -323,9 +321,10 @@ bfloat16x8_t test_vcvtq_low_bf16_f32(float32x4_t a) {
// CHECK-A64-NEXT: entry:
// CHECK-A64-NEXT:[[TMP0:%.*]] = bitcast <8 x bfloat> [[INACTIVE:%.*]] to
<16 x i8>
// CHECK-A64-NEXT:[[TMP1:%.*]] = bitcast <4 x float> [[A:%.*]] to <16 x i8>
-// CHE
davemgreen wrote:
Is this a system-reg only extension?
It was enabled in #115296, which has an explanation why it was enabled.
I'm not sure how well we implement the sys-reg only extensions always being
enabled idea, or if the best way to handle that is making them required
features. But this
davemgreen wrote:
I agree the current behaviour isn't very consistent. It would be good to come
up with a single rule and stick to it, whatever it is. FeatureAMVS /
FEAT_AMUv1p1 came up recently too, which is enabled for some cpus that do not
have it (like Neoverse V3).
It looks like GCC is t
https://github.com/davemgreen approved this pull request.
Thanks LGTM. Let us know if we should squash and merge (I never know who has
access).
https://github.com/llvm/llvm-project/pull/122965
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
@@ -2033,6 +2041,25 @@ bool
AArch64TargetLowering::shouldExpandGetActiveLaneMask(EVT ResVT,
return false;
}
+bool AArch64TargetLowering::shouldExpandGetAliasLaneMask(
davemgreen wrote:
Can this be removed now?
https://github.com/llvm/llvm-project/pull/117
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/117007
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -567,6 +567,9 @@ std::string SDNode::getOperationName(const SelectionDAG *G)
const {
case ISD::EXPERIMENTAL_VECTOR_HISTOGRAM:
return "histogram";
+ case ISD::EXPERIMENTAL_ALIAS_LANE_MASK:
+return "alias_mask";
davemgreen wrote:
alias_lane_mask
https://github.com/davemgreen commented:
If you want to upgrade the whilewr intrinsics (which I think sounds OK to me),
then it will need auto-update code something like in
https://github.com/llvm/llvm-project/pull/120363/files#diff-0c0305d510a076cef711c006c1d9fd78c95cade1f597d21ee46fd753e69823
@@ -334,8 +334,8 @@ ARM_CPU_NAME("cortex-r7", ARMV7R, FK_VFPV3_D16_FP16, false,
(ARM::AEK_MP | ARM::AEK_HWDIVARM))
ARM_CPU_NAME("cortex-r8", ARMV7R, FK_VFPV3_D16_FP16, false,
(ARM::AEK_MP | ARM::AEK_HWDIVARM))
-ARM_CPU_NAME("cortex-r52", ARMV8R, FK_NEO
@@ -0,0 +1,8040 @@
+//===-- AArch64.cpp - Emit LLVM Code for builtins
-===//
davemgreen wrote:
This looks like it should be Arm.cpp, as it is the common code between the Arm
and AArch64 backends.
https://github.com/llvm/llvm-project/pul
https://github.com/davemgreen approved this pull request.
Thanks, LGTM
https://github.com/llvm/llvm-project/pull/132368
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
davemgreen wrote:
Sorry for the delay, my computer got very slow at building things. - What goes
wrong if ARM::AEK_SIMD is removed from the CPU and architecture definitions? If
it is needed then there are some other cpu's where it might need to be added
too. But I'm not sure what needs it. (Ta
https://github.com/davemgreen commented:
Thanks - this looks good.
https://github.com/llvm/llvm-project/pull/130623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1067,7 +1067,8 @@ def ProcessorFeatures {
FeatureDotProd, FeatureFPARMv8,
FeatureMatMulInt8,
FeatureSSBS, FeatureCCIDX,
FeatureJS, FeatureLSE, FeatureRAS,
Featur
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/135064
>From 33a204bcc884178971c4327528b1e3b75336914e Mon Sep 17 00:00:00 2001
From: David Green
Date: Wed, 9 Apr 2025 11:18:25 +0100
Subject: [PATCH 1/4] [AArch64] Add a test case for the coerced arguments. NFC
--
@@ -485,6 +485,24 @@ ABIArgInfo AArch64ABIInfo::classifyArgumentType(QualType
Ty, bool IsVariadicFn,
}
Size = llvm::alignTo(Size, Alignment);
+// If the Aggregate is made up of pointers, use an array of pointers for
the
+// coerced type. This prevents having
@@ -679,21 +679,17 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind :
ArchArgFPUKind;
(void)llvm::ARM::getFPUFeatures(FPUKind, Features);
} else {
-bool Generic = true;
-if (!ForAS) {
https://github.com/davemgreen approved this pull request.
The other thing this patch does is bring the preprocessor features for
-march=armv8.1-m in line with the assembly features. It was previously enabling
__ARM_VFPV2__ but not allowing vfpv2 instructions.
I'm still not sure about the Win/D
=?utf-8?q?Csan=C3=A1d_Hajd=C3=BA?=
Message-ID:
In-Reply-To:
https://github.com/davemgreen approved this pull request.
Thanks, LGTM
https://github.com/llvm/llvm-project/pull/134802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
https://github.com/davemgreen created
https://github.com/llvm/llvm-project/pull/135064
The aim here is to avoid a ptrtoint->inttoptr round-trip through the function
argument whilst keeping the calling convention the same. Given a struct which
is <= 128bits in size, which can only contain either
@@ -38,6 +38,9 @@ Potentially Breaking Changes
- Fix missing diagnostics for uses of declarations when performing typename
access,
such as when performing member access on a '[[deprecated]]' type alias.
(#GH58547)
+- For ARM targets, when using cc1as, the features included
davemgreen wrote:
NEON is never mandatory AFAIU in the architecture (FP too). We might assume it
to be present though, as I believe it comes from the default -mfpu. (For
example FK_CRYPTO_NEON_FP_ARMV8 from armv8-a).
Using something like this: https://godbolt.org/z/EKEMsaMdW. If I take this
p
https://github.com/davemgreen approved this pull request.
Thanks. LGTM
https://github.com/llvm/llvm-project/pull/130623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/135064
>From 8655b5aff2162bfc13d3f263d6b7830e0186c097 Mon Sep 17 00:00:00 2001
From: David Green
Date: Wed, 9 Apr 2025 11:18:25 +0100
Subject: [PATCH 1/2] [AArch64] Add a test case for the coerced arguments. NFC
--
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/135064
>From 8655b5aff2162bfc13d3f263d6b7830e0186c097 Mon Sep 17 00:00:00 2001
From: David Green
Date: Wed, 9 Apr 2025 11:18:25 +0100
Subject: [PATCH 1/2] [AArch64] Add a test case for the coerced arguments. NFC
--
@@ -485,6 +485,39 @@ ABIArgInfo AArch64ABIInfo::classifyArgumentType(QualType
Ty, bool IsVariadicFn,
}
Size = llvm::alignTo(Size, Alignment);
+// If the Aggregate is made up of pointers, use an array of pointers for
the
+// coerced type. This prevents having
https://github.com/davemgreen approved this pull request.
Thanks. LGTM
https://github.com/llvm/llvm-project/pull/137330
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/davemgreen closed
https://github.com/llvm/llvm-project/pull/137330
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
davemgreen wrote:
I believe the backend would still need work to make sure this is supported,
which has not been done yet. I was expecting it to fail more noisily, but it
appears the strict nodes are lowered to generic nodes. That doesn't mean that
strict-fp is supported by the Arm backend, as
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/135064
>From 33a204bcc884178971c4327528b1e3b75336914e Mon Sep 17 00:00:00 2001
From: David Green
Date: Wed, 9 Apr 2025 11:18:25 +0100
Subject: [PATCH 1/5] [AArch64] Add a test case for the coerced arguments. NFC
--
@@ -679,21 +679,17 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind :
ArchArgFPUKind;
(void)llvm::ARM::getFPUFeatures(FPUKind, Features);
} else {
-bool Generic = true;
-if (!ForAS) {
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/135064
>From 33a204bcc884178971c4327528b1e3b75336914e Mon Sep 17 00:00:00 2001
From: David Green
Date: Wed, 9 Apr 2025 11:18:25 +0100
Subject: [PATCH 1/6] [AArch64] Add a test case for the coerced arguments. NFC
--
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/130623
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -419,6 +419,9 @@ Bug Fixes to Attribute Support
- No longer crashing on ``__attribute__((align_value(N)))`` during template
instantiation when the function parameter type is not a pointer or reference.
(#GH26612)
+- The ``+nosimd`` attribute is now fully supported for AA
@@ -201,6 +201,42 @@ SVE_OPAQUE_TYPE(__SVCount_t, __SVCount_t, SveCount,
SveCountTy)
SVE_SCALAR_TYPE(__mfp8, __mfp8, MFloat8, MFloat8Ty, 8)
+// Unlike the SVE types above, the Neon vector types are parsed as keywords and
+// mapped to the equivalent __attribute__(neon_vector
https://github.com/davemgreen commented:
Hi - I tried this with the latest
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/config/cpu/aarch64/opt/ext/opt_random.h
and it seemed to need some fixes and then it might have failed to mangle the
types if they were used? I can provide
https://github.com/davemgreen edited
https://github.com/llvm/llvm-project/pull/126945
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -201,6 +201,42 @@ SVE_OPAQUE_TYPE(__SVCount_t, __SVCount_t, SveCount,
SveCountTy)
SVE_SCALAR_TYPE(__mfp8, __mfp8, MFloat8, MFloat8Ty, 8)
+// Unlike the SVE types above, the Neon vector types are parsed as keywords and
+// mapped to the equivalent __attribute__(neon_vector
@@ -1366,6 +1366,13 @@ static QualType
ConvertDeclSpecToType(TypeProcessingState &state) {
break;
#include "clang/Basic/OpenCLImageTypes.def"
+#define NEON_VECTOR_TYPE(Name, BaseType, ElBits, NumEls, VectorKind)
\
+ case DeclSpec::TST_##Name:
@@ -201,6 +201,42 @@ SVE_OPAQUE_TYPE(__SVCount_t, __SVCount_t, SveCount,
SveCountTy)
SVE_SCALAR_TYPE(__mfp8, __mfp8, MFloat8, MFloat8Ty, 8)
+// Unlike the SVE types above, the Neon vector types are parsed as keywords and
+// mapped to the equivalent __attribute__(neon_vector
davemgreen wrote:
@john-brawn-arm did the work for AArch64, I'm not sure if he would have an idea
how much work it would involve for the Arm backend.
https://github.com/llvm/llvm-project/pull/137101
___
cfe-commits mailing list
cfe-commits@lists.llvm.
@@ -862,7 +862,7 @@ def ProcessorFeatures {
FeatureSB, FeatureSSBS, FeaturePAuth,
FeatureFlagM, FeaturePredRes,
FeatureSVE, FeatureSVE2, FeatureComplxNum,
FeatureCRC, FeatureDotProd,
https://github.com/davemgreen updated
https://github.com/llvm/llvm-project/pull/135064
>From d9e27ec881ec493174f3aee7a4faec567640e5e8 Mon Sep 17 00:00:00 2001
From: David Green
Date: Wed, 9 Apr 2025 11:18:25 +0100
Subject: [PATCH 1/3] [AArch64] Add a test case for the coerced arguments. NFC
--
201 - 300 of 394 matches
Mail list logo
