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
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
@@ -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
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 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
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
@@ -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
@@ -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
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
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:
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 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:
> 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 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:
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:
> 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:
> 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 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
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
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
@@ -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
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
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 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
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
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
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.
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:
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:
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
___
@@ -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
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
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:
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
@@ -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
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 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
@@ -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
@@ -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:
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
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
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
___
1 - 100 of 244 matches
Mail list logo
