[PATCH] D90765: [ARM][AArch64] Adding Neoverse V1 CPU support

dmgreen added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64Subtarget.cpp:198 break; + case NeoverseV1: +PrefFunctionLogAlignment = 4; Please put with the other cpus above. Comment at: llvm/lib/Target/AArch64/AArch64Subt

[PATCH] D90765: [ARM][AArch64] Adding Neoverse V1 CPU support

dmgreen added inline comments. Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:154-155 +AARCH64_CPU_NAME("neoverse-v1", ARMV8_4A, FK_CRYPTO_NEON_FP_ARMV8, false, + (AArch64::AEK_RAS | AArch64::AEK_SVE | AArch64::AEK_SSBS | + AArch64:

[PATCH] D90765: [ARM][AArch64] Adding Neoverse V1 CPU support

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks. LGTM Comment at: llvm/unittests/Support/TargetParserTest.cpp:10-11 #include "llvm/Support/TargetParser.h" #include "llvm/ADT/STLExtras.h" +#include "llvm/Support/

[PATCH] D91695: [ARM][AArch64] Adding Neoverse N2 CPU support

dmgreen added a comment. Can you add the cpuid to host.cpp too? Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:154 +AARCH64_CPU_NAME("neoverse-n2", ARMV8_5A, FK_CRYPTO_NEON_FP_ARMV8, false, + (AArch64::AEK_BF16 | AArch64::AEK_DOTPROD | AArch64::AE

[PATCH] D88566: be more specific when testing for no fuse-ld warnings

dmgreen added a comment. In the past we have usually disabled the downstream warning for similar catch-all warning lines. Comment at: clang/test/Driver/fuse-ld.c:5 // RUN: FileCheck %s --check-prefix=CHECK-ABSOLUTE-LD // CHECK-ABSOLUTE-LD: warning: '-fuse-ld=' taking a pat

[PATCH] D88566: be more specific when testing for no fuse-ld warnings

dmgreen added a comment. (Not that I'm against this, either way sounds fine to me) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88566/new/ https://reviews.llvm.org/D88566 ___ cfe-commits mailing list cf

[PATCH] D87451: add new option -mignore-xcoff-visibility

dmgreen added a comment. Hello. I added a power-pc REQUIRES clause to the new clang test here in a15bd0bfc20c2b2955c59450a67b6e8efe89c708 . Hope that looks OK. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D91695: [ARM][AArch64] Adding Neoverse N2 CPU support

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks for the changes. From what I can tell, this LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91695/new/ https://reviews.llvm.org/D91

[PATCH] D102397: [AArch64] Lower bitreverse in ISel

dmgreen added a comment. Sounds good. Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:4134 -defm RBIT : SIMDTwoVectorB<1, 0b01, 0b00101, "rbit", int_aarch64_neon_rbit>; +//defm RBIT : SIMDTwoVectorB<1, 0b01, 0b00101, "rbit", int_aarch64_neon_rbit>; +defm RBIT :

[PATCH] D102397: [AArch64] Lower bitreverse in ISel

dmgreen added inline comments. Comment at: llvm/lib/IR/AutoUpgrade.cpp:556 } +if (Name.startswith("aarch64.neon.rbit")) { + NewFn = Intrinsic::getDeclaration(F->getParent(), Intrinsic::bitreverse, Do we have a test for the autoupgrade, to show that

[PATCH] D100919: [AArch64] Support customizing stack protector guard

dmgreen accepted this revision. dmgreen added a comment. Thanks. This sounds good to me, if David agrees. Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:1912 +if (!SrcReg) + report_fatal_error("Unknow SysReg for Stack Protector Guard Register"); + ---

[PATCH] D102397: [AArch64] Lower bitreverse in ISel

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks. LGTM Comment at: llvm/test/CodeGen/AArch64/neon_rbit.ll:9 + +define <8 x i8> @rbit_8x8(<8 x i8> %A) nounwind { +; CHECK-LABEL: rbit_8x8: v8i8 and v

[PATCH] D102238: [TableGen] [Clang] Clean up arm_mve.td file

dmgreen accepted this revision. dmgreen added a comment. Sorry. I think we were waiting for the foldl comment to be removed. If you remove that, this LGTM. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102238/new/ https://reviews.llvm.org/D102238 __

[PATCH] D94779: [Clang] Ensure vector predication pragma is ignored only when vectorization width is 1.

dmgreen added a comment. Thanks. @fhahn @SjoerdMeijer what do we think about the edge case where the width==1? As far as I understand (with this patch): #pragma clang loop vectorize_predicate(disable) vectorize_width(4) Gives llvm.loop.vectorize.predicate.enable=false, llvm.loop.vectorize.w

[PATCH] D110258: [AArch64][Clang] Always add -tune-cpu argument to -cc1 driver

dmgreen added a comment. My understanding is that -mtune doesn't work sensibly for Arm backends. The tuning features and architecture features are not separated out at the subtarget level. Is the idea to teach people to start using it? That sounds dangerous without fixing the issues with it fi

[PATCH] D110258: [AArch64][Clang] Always add -tune-cpu argument to -cc1 driver

dmgreen added a comment. In D110258#3015484 , @david-arm wrote: > Hi @dmgreen, this is specifically being introduced for SVE targets to help > make informed cost model decisions regarding the value of vscale - see > D110259

[PATCH] D110258: [AArch64] Always add -tune-cpu argument to -cc1 driver

dmgreen added a comment. Sounds great. Glad to see us taking this route. Unfortunately I think we do need to split the subtargetfeatures up into arch flags and tune flags. Same for the details in AArch64Subtarget::initializeProperties. It is hopefully a fairly mechanical process, but they are

[PATCH] D110258: [AArch64] Always add -tune-cpu argument to -cc1 driver

dmgreen added a comment. I think ProcessorModel is class ProcessorModel f, list tunef = []> So we are always currently passing tunef = [] from AArch64 and passing all features through f. They need to be split out and then hopefully the call to ParseSubtargetFeatures w

[PATCH] D110258: [AArch64] Always add -tune-cpu argument to -cc1 driver

dmgreen added a comment. I think these are the features I would class as tuning: FeatureExperimentalZeroingPseudos FeatureZCRegMove FeatureZCZeroingGP FeatureNoZCZeroingFP FeatureZCZeroing FeatureZCZeroingFPWorkaround FeatureStrictAlign FeatureBalanceFPOps FeaturePredictableSele

[PATCH] D110258: [AArch64] Always add -tune-cpu argument to -cc1 driver

dmgreen added a comment. In D110258#3024418 , @david-arm wrote: > Hi @dmgreen, would you be happy for me to do the splitting-out of arch and > tuning features in a separate follow-on patch? I think it's a good idea and I > don't object to doing it, but

[PATCH] D94779: [Clang] Ensure vector predication pragma is ignored only when vectorization width is 1.

dmgreen added a comment. This makes sense to me. If the user specifies the pragma then we send that through to the vectorizer, whatever it is. As much as `vectorize_width(1) interleave_count(4) vectorize_predicate(enable)` doesn't make a lot of sense, it's still something that should work. And

[PATCH] D94779: [Clang] Ensure vector predication pragma is ignored only when vectorization width is 1.

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. OK Thanks. LGTM Comment at: clang/test/CodeGenCXX/pragma-loop-predicate.cpp:88 + +#pragma clang loop vectorize_predicate(enable) vectorize_width(1) + for (int i = 0; i < L

[PATCH] D94779: [Clang] Ensure vector predication loop metadata is always emitted when pragma is specified.

dmgreen added a comment. Thanks for your comments. This patch is not intended to have no consequence - it's just not being communicated well in the commit message. The problem at the moment, with mainline clang, is that specifying: #pragma clang loop vectorize_width(4) vectorize_predicate(ena

[PATCH] D108138: [SimplifyCFG] Remove switch statements before vectorization

dmgreen added a comment. > I'm under the impression that the vectoriser has a policy of never making > scalar transformations I'm not sure what you mean. I've not looked into the details, but it could presumably be done as some sort of VPlan transformation, possibly in the constructions of vpl

[PATCH] D108138: [SimplifyCFG] Remove switch statements before vectorization

dmgreen added a comment. In D108138#2948995 , @david-arm wrote: > In D108138#2948975 , @dmgreen wrote: > >>> I'm under the impression that the vectoriser has a policy of never making >>> scalar transformations >>

[PATCH] D112406: [Driver][AArch64]Add driver support for neoverse-512tvb target

dmgreen added a comment. Thanks. If the cpu has a 512 bit total vector bandwidth, should the VScaleForTuning be 1 or 2 (or higher)? llvm doesn't usually deal with total bandwidth a lot, perhaps not as much as it should. @david-arm any thoughts? Repository: rG LLVM Github Monorepo CHANGES S

[PATCH] D112459: [AArch64] Enablement of Cortex-X2

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D112459/new/ https://reviews.llvm.org/D112459 ___ cfe-commits mailing list cfe

[PATCH] D112406: [Driver][AArch64]Add driver support for neoverse-512tvb target

dmgreen added a comment. > The total vector bandwidth includes unrolling so currently having > `VScaleForTuning=1` and `MaxInterleaveFactor=4` implies 512 tvb. If the > target has >128bit vectors then vector loops will likely have more work than > they can handle in parallel but as long as tha

[PATCH] D112459: [AArch64] Enablement of Cortex-X2

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG0b83a18a2b9d: [AArch64] Enablement of Cortex-X2 (authored by mubashar_, committed by dmgreen). Changed prior to commit: https://reviews.llvm.org/D

[PATCH] D113256: [AArch64][ARM] Enablement of Cortex-A710 Support

dmgreen added inline comments. Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:159-160 AArch64::AEK_RCPC | AArch64::AEK_SSBS)) +AARCH64_CPU_NAME("cortex-a710", ARMV9A, FK_NEON_FP_ARMV8, false, + (AArch64::AEK_MTE | AArch64::AEK_PAU

[PATCH] D113256: [AArch64][ARM] Enablement of Cortex-A710 Support

dmgreen added inline comments. Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:159-160 AArch64::AEK_RCPC | AArch64::AEK_SSBS)) +AARCH64_CPU_NAME("cortex-a710", ARMV9A, FK_NEON_FP_ARMV8, false, + (AArch64::AEK_MTE | AArch64::AEK_PAU

[PATCH] D113256: [AArch64][ARM] Enablement of Cortex-A710 Support

dmgreen added inline comments. Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:181 + AArch64::AEK_SVE2BITPERM | AArch64::AEK_BF16)) AARCH64_CPU_NAME("cortex-a78c", ARMV8_2A, FK_CRYPTO_NEON_FP_ARMV8, false, (AArch64::AEK_FP16 | AAr

[PATCH] D113256: [AArch64][ARM] Enablement of Cortex-A710 Support

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113256/new/ https://reviews.llvm.org/D113256 ___ cfe-commits mailing list cfe

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

dmgreen added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:1495 let DecoderNamespace = "Fallback"; + let Defs = [NZCV]; } SjoerdMeijer wrote: > Do all MRS instructions do this? No, but some do and it's not obvious which ones do

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

dmgreen added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:15993 + DAG.getConstant(0, dl, MVT::i32), + DAG.getConstant(AArch64CC::EQ, dl, MVT::i32), A.getValue(1)); + return DAG.getMergeValues( Can you make s

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

dmgreen added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:1495 let DecoderNamespace = "Fallback"; + let Defs = [NZCV]; } stelios-arm wrote: > SjoerdMeijer wrote: > > SjoerdMeijer wrote: > > > dmgreen wrote: > > > > SjoerdMeije

[PATCH] D98510: [Clang][ARM] Reenable arm_acle.c test.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG2b3c81314343: [Clang][ARM] Reenable arm_acle.c test. (authored by dmgreen). Herald added a project: clang. Herald added a subscriber: cfe-commits. C

[PATCH] D93164: [AST] Add generator for source location introspection

dmgreen added a comment. Hello. Does this work when the default target triple isn't native? This seems to be trying to compile clang sources with the just built clang - something that I don't think is always possible. I'm seeing errors like `fatal error: 'cstddef' file not found`, and failing t

[PATCH] D98487: [AArch64][SVE/NEON] Add support for FROUNDEVEN for both NEON and fixed length SVE

dmgreen added inline comments. Comment at: llvm/include/llvm/IR/IntrinsicsAArch64.td:476 - // intrinsic. - def int_aarch64_neon_frintn : AdvSIMD_1FloatArg_Intrinsic; - If you are removing the old intrinsic (which is great), then it will need some AutoUpgrade c

[PATCH] D98487: [AArch64][SVE/NEON] Add support for FROUNDEVEN for both NEON and fixed length SVE

dmgreen added a comment. Thanks. This looks sensible, from what I can tell. Comment at: llvm/include/llvm/Target/TargetSelectionDAG.td:158 ]>; +def SDTFPRoundEvenOp : SDTypeProfile<1, 1, [ // froundeven + SDTCisFP<0>, SDTCisFP<1>, SDTCisOpSmallerThanOp<0, 1>, SDTCisSameNu

[PATCH] D135646: [AArch64] Alter v8.5a FRINT neon intrinsics to be target-based, not preprocessor based

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG6f1e43036059: [AArch64] Alter v8.5a FRINT neon intrinsics to be target-based, not… (authored by dmgreen). Herald added a project: clang. Herald added

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

dmgreen added reviewers: lenary, dmgreen. dmgreen added inline comments. Comment at: clang/docs/ReleaseNotes.rst:397 configuration files. +- Support has been added for the following processors (-mcpu identifiers in parentheses): + This should be in the "Arm a

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

dmgreen added a comment. Can you also add a test to clang/test/Driver/aarch64-mcpu.c and the right code to llvm/lib/Support/Host.cpp if you can find it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136589/new/ https://reviews.llvm.org/D136589 __

[PATCH] D135615: [AArch64][ARM] Alter v8.1a neon intrinsics to be target-based, not preprocessor based

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG9c48b7f0e7a9: [AArch64][ARM] Alter v8.1a neon intrinsics to be target-based, not preprocessor… (authored by dmgreen). Herald added a project: clang.

[PATCH] D135647: [AArch64][ARM] Alter v8.3a complex neon intrinsics to be target-based, not preprocessor based

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGaf1bb287b4de: [AArch64][ARM] Alter v8.3a complex neon intrinsics to be target-based, not… (authored by dmgreen). Herald added a project: clang. Heral

[PATCH] D136957: [AArch64] Add support for the Cortex-A715 CPU

dmgreen added inline comments. Comment at: llvm/lib/Support/Host.cpp:216 .Case("0xd41", "cortex-a78") +.Case("0xd00", "cortex-a715") .Case("0xd44", "cortex-x1") Should be 0xd4d I think, according to the MIDR in the TRM. ===

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

dmgreen added inline comments. Comment at: clang/docs/ReleaseNotes.rst:629-631 - Add driver and tuning support for Neoverse V2 via the flag ``-mcpu=neoverse-v2``. Native detection is also supported via ``-mcpu=native``. +- Support has been added for the following processors

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

dmgreen added a comment. Thanks. What was wrong with the v9-A features? Comment at: llvm/unittests/Support/TargetParserTest.cpp:1083 + AArch64::AEK_SVE | AArch64::AEK_SVE2 | + AArch64::AEK_SVE2BITPERM | AArch64::AEK_SB | +

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

dmgreen added a subscriber: david-arm. dmgreen added inline comments. Comment at: clang/docs/ReleaseNotes.rst:696 -- Add driver and tuning support for Neoverse V2 via the flag ``-mcpu=neoverse-v2``. - Native detection is also supported via ``-mcpu=native``. t

[PATCH] D131547: [Clang][AArch64] Use generic extract/insert vector for svget/svset/svcreate tuples

dmgreen added a comment. I think we usually try to do the same, if the intrinsics have been in released compilers. There is an example in https://reviews.llvm.org/D98487#change-tOTTgECYYAO5, hopefully these would be equally simple. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACT

[PATCH] D131547: [Clang][AArch64] Use generic extract/insert vector for svget/svset/svcreate tuples

dmgreen added a comment. In D131547#3728842 , @sdesmalen wrote: > In D131547#3723083 , @dmgreen wrote: > >> I think we usually try to do the same, if the intrinsics have been in >> released compilers. There is an

[PATCH] D131547: [Clang][AArch64] Use generic extract/insert vector for svget/svset/svcreate tuples

dmgreen added a comment. > Is there a formal requirement that LLVM must remain backward compatible with > older LLVM IR (beyond the target-independent parts)? We have always done it in the past, and I don't see a good reason to change. This change is essentially for llvm 16, so we are talking a

[PATCH] D134127: [ARM] Check target feature support for __builtin_arm_crc*

dmgreen added reviewers: danielkiss, ilinpv. dmgreen added a comment. This looks like a subset of D133359 ? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134127/new/ https://reviews.llvm.org/D134127 __

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

dmgreen added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64.td:941 + "Neoverse V2 ARM processors", [ + FeaturePostRAScheduler]>; + Please add FeatureFuseAES and FeatureLSLFas

[PATCH] D134127: [ARM] Check target feature support for __builtin_arm_crc*

dmgreen added a comment. The arm_acle.h header is shared across Arm and AArch64 - they use the same builtin names even if they are replicated to a certain degree across the backends. As this is used in both it would be good to fix them at the same time. It doesn't need to change the guards as D

[PATCH] D134127: [ARM] Check target feature support for __builtin_arm_crc*

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Whether you do that here or in another patch, the change LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134127/new/ https://reviews.llvm.

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

dmgreen added a comment. Thanks. Should RNG be added? And Why is Crypto no longer enabled? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134352/new/ https://reviews.llvm.org/D134352 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

dmgreen added a comment. Oh, A release note would be good to add too. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134352/new/ https://reviews.llvm.org/D134352 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cg

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

dmgreen added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64.td:1112 + FeatureNEON, FeatureSVE2BitPerm, FeatureFP16FML, + FeatureMTE, FeatureRandGen]; list Saphira= [HasV8_4aOps, Fea

[PATCH] D134352: [AArch64] Add Neoverse V2 CPU support

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134352/new/ https://reviews.llvm.org/D134352 ___ cfe-commits mailing list cfe

[PATCH] D134717: [Clang][AArch64] Fix va_arg with -mgeneral-regs-only

dmgreen added a comment. > With -mgeneral-regs-only, all arguments are passed in GPRs, so we should use > gr_top/gr_offs in va_list even for floating-point types. I don't believe that -mgeneral-regs-only was intended to define an ABI passing floats in GPRs for AArch64. If it has that is likely

[PATCH] D133885: [Clang][Arm] Convert -fallow-half-arguments-and-returns to a target option. NFC

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG123064dc397d: [Clang][Arm] Convert -fallow-half-arguments-and-returns to a target option. NFC (authored by dmgreen). Herald added a project: clang.

[PATCH] D133848: [Clang][AArch64] Support AArch64 target(..) attribute formats.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG781b491bba9d: [Clang][AArch64] Support AArch64 target(..) attribute formats. (authored by dmgreen). Herald added a project: clang. Herald added a sub

[PATCH] D131504: [ARM][AArch64] Dont use macros for half instrinsics in NeonEmitter

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG4987ae84622b: [ARM][AArch64] Dont use macros for half instrinsics in NeonEmitter (authored by dmgreen). Herald added a project: clang. Herald added a

[PATCH] D140432: [AArch64] Guard {vmull_p64, vmull_high_p64} with 'aes' target guard.

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks for putting together the patch. It may be worth mentioning in the commit message that aes currently includes both FEAT_AES and FEAT_PMULL. Otherwise LGTM. Repository: rG LLVM Githu

[PATCH] D131064: [AArch64] Alter arm_sve.h to be target-based, not preprocessor based.

This revision was automatically updated to reflect the committed changes. Closed by commit rG6cac7c285e69: [AArch64] Alter arm_sve.h to be target-based, not preprocessor based. (authored by dmgreen). Herald added a project: clang. Herald added a subscriber: cfe-commits. Changed prior to commit:

[PATCH] D132639: [AArch64] Alter arm_neon_sve_bridge.h to be target-based, not preprocessor based.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG997852920d52: [AArch64] Alter arm_neon_sve_bridge.h to be target-based, not preprocessor… (authored by dmgreen). Herald added a project: clang. Heral

[PATCH] D141411: [AArch64] Make -march and target("arch=..") attributes imply dependent features

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG0c0127bb9f00: [AArch64] Make -march and target(arch=..) attributes imply dependent features (authored by dmgreen). Herald added a project: clang. Her

[PATCH] D141411: [AArch64] Make -march and target("arch=..") attributes imply dependent features

dmgreen added a comment. In D141411#4042891 , @lenary wrote: > Can we check this logic, especially around adding both AEK_SVE and AEK_SVE2 > in the `AARCH64_ARCH` descriptions, this means that `-march=armv9-a+nosve2` > still can generate sve instruction

[PATCH] D141404: [AArch64][Clang] Adjust default features for v8.9-A/v9.4-A in clang driver

dmgreen added a comment. Do you know why this code is in the Driver? I would have expected mandatory features to be added to the AARCH64_ARCH in AArch64TargetParser.td. I don't think they are then needed in the driver. I can put up a patch to show what I mean, as I think the same applies to i8

[PATCH] D141404: [AArch64][Clang] Adjust default features for v8.9-A/v9.4-A in clang driver

dmgreen added a comment. I've put up D141518 to move the existing features. Let me know what you think Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141404/new/ https://reviews.llvm.org/D141404 _

[PATCH] D141411: [AArch64] Make -march and target("arch=..") attributes imply dependent features

dmgreen added a comment. It does look like this might be enabling Crypto in places it was not in the past though. I'll look into why that is. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141411/new/ https://reviews.llvm.org/D141411 _

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

dmgreen added inline comments. Comment at: clang/docs/ReleaseNotes.rst:696 -- Add driver and tuning support for Neoverse V2 via the flag ``-mcpu=neoverse-v2``. - Native detection is also supported via ``-mcpu=native``. vhscampos wrote: > tschuett wrote: > > d

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks. LGTM if there are not other comments Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136589/new/ https://reviews.llvm.org/D136589 _

[PATCH] D137256: [AArch64] Alter arm_fp16.h to be target-based, not preprocessor based.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGe7deca525058: [AArch64] Alter arm_fp16.h to be target-based, not preprocessor based. (authored by dmgreen). Herald added a project: clang. Herald add

[PATCH] D137617: [AArch64] Allow users-facing feature names in clang target attributes

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGf0e6c403c2d3: [AArch64] Allow users-facing feature names in clang target attributes (authored by dmgreen). Herald added a project: clang. Herald adde

[PATCH] D142410: [AArch64] ARMv8.5-A implies both FEAT_SB and FEAT_SSBS

dmgreen added reviewers: lenary, tmatheson, pratlucas. dmgreen added a comment. I believe this is correct, according to at least one reference I have. FEAT_SSBS isn't spelled out very clearly in the reference manual though. Adding some more people who might be able to check. Repository: rG L

[PATCH] D142396: [AArch64] Add the Ampere1A core

dmgreen added a comment. Sounds OK, but do you mind splitting FeatureFuseAddSub2RegAndConstOne into a separate patch. They seem to be logically separable, and it can help in case there are problems found in one of the patches. Comment at: llvm/include/llvm/TargetParser/AArch6

[PATCH] D142396: [AArch64] Add the Ampere1A core

dmgreen added inline comments. Comment at: llvm/include/llvm/TargetParser/AArch64TargetParser.h:492 +{"ampere1a", ARMV8_6A, + (AArch64::AEK_FP16 | AArch64::AEK_RAND | AArch64::AEK_SM4 | + AArch64::AEK_SHA3 | AArch64::AEK_SHA2 | AArch64::AEK_AES | Jus

[PATCH] D142396: [AArch64] Add the Ampere1A core

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. OK Thanks for the clarification. LGTM then. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D142396/new/ https://reviews.llvm.org/D142396 __

[PATCH] D127910: [Clang][AArch64][SME] Add vector load/store (ld1/st1) intrinsics

dmgreen added inline comments. Comment at: clang/utils/TableGen/SveEmitter.cpp:1477 + + OS << "#if !defined(__ARM_FEATURE_SME)\n"; + OS << "#error \"SME support not enabled\"\n"; We have been changing how the existing SVE and NEON instrinsics work a little. Th

[PATCH] D142548: [AArch64] Replace AEK_CRYPTO with relevant features in cpu definitions

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG8f6c623e8746: [AArch64] Replace AEK_CRYPTO with relevant features in cpu definitions (authored by dmgreen). Herald added a project: clang. Herald add

[PATCH] D142988: [AArch64] Make nosimd imply nocrypto

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG00ce96b02e87: [AArch64] Make nosimd imply nocrypto (authored by dmgreen). Herald added a project: clang. Herald added a subscriber: cfe-commits. Rep

[PATCH] D142963: [AArch64] Handle negative architecture features

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGf559e781b2bd: [AArch64] Handle negative architecture features (authored by dmgreen). Herald added a project: clang. Herald added a subscriber: cfe-co

[PATCH] D131058: [AArch64] Add an error if SVE scalable vector types are used in a context without sve

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG753aca0a3ab0: [AArch64] Add an error if SVE scalable vector types are used in a context… (authored by dmgreen). Herald added a project: clang. Herald

[PATCH] D141056: [SVE][CGBuiltins] Remove need for instcombine from ACLE tests.

dmgreen added a comment. I removed -O1 from clang sve tests a while ago. The intent was always to remove instcombine and tailcallelim too, but I never got around to it. Feel free to remove -O1 from the other sve2 tests too, they ideally shouldn't test the entire pipeline from clang. Repositor

[PATCH] D141518: [AArch64] Move default extensions from clang Driver to TargetParser

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG0f422215ac63: [AArch64] Move default extensions from clang Driver to TargetParser (authored by dmgreen). Herald added a project: clang. Herald added

[PATCH] D142087: [AArch64] Armv9-A implies FP16

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGee700dec052a: [AArch64] Armv9-A implies FP16 (authored by dmgreen). Herald added a project: clang. Herald added a subscriber: cfe-commits. Changed p

[PATCH] D141606: [AArch64] Remove AES, SHA2, SHA3 and SM4 features from armv8.6-a+

dmgreen added a comment. In D141606#4074204 , @ilinpv wrote: > Sorry, commit rG5474d7d93271 > is not > related to this, I put wrong differential revision link Not a problem, I was ju

[PATCH] D128415: [ARM] Add Support for Cortex-M85

dmgreen added inline comments. Comment at: llvm/lib/Target/ARM/ARM.td:1443 +def : ProcessorModel<"cortex-m85", CortexM4Model, [ARMv81mMainline, + FeatureDSP, Please use the CortexM7 schedule - it is

[PATCH] D158008: [AArch64] Add patterns for FMADD, FMSUB

dmgreen added a comment. It looks like there are patterns for A[0]*B+C and B*A[0]*C to handle commutivity. Are there tests for both forms too? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158008/new/ https://reviews.llvm.org/D158008

[PATCH] D158626: [AArch64] Add missing vrnd intrinsics

dmgreen added a comment. Sounds good. Can you make sure you upload with context, it makes the patches easier to read in phabricator: https://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:6297

[PATCH] D156799: Update generic scheduling to use A510 scheduling model

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks. Looks good. You may need to rebase over new tests, make sure everything is still passing when you do. LGTM Comment at: llvm/test/CodeGen/AArch64/misched-detail-re

[PATCH] D159480: [Clang][AArch64] Fine-grained ldp and stp policies.

dmgreen added a comment. Can you give more details about why this is wanted and in which cases it helps with? Is it an optimization, as opposed to working around some correctness issue? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D159480/new/ ht

[PATCH] D158626: [AArch64] Add missing vrnd intrinsics

dmgreen accepted this revision. dmgreen added a comment. This revision is now accepted and ready to land. Thanks. LGTM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158626/new/ https://reviews.llvm.org/D158626 ___ cfe-commits mailing list cfe

[PATCH] D159480: [Clang][AArch64] Fine-grained ldp and stp policies.

dmgreen added a comment. We do not usually add front-end clang options for optimizations like this. Users are more likely to use them incorrectly, or just not know that they exist. The usual method would be to make a subtarget tuning feature that controls whether ldp are created, and enable it

[PATCH] D159174: [Clang] Use stable_sort in AppendTargetMangling

dmgreen added a comment. Do you have a test-case where they were out of order? Or is that dependent on the C++ library? I think I just moved this code from elsewhere when I changed it, but it sounds like a sensible change to me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D158626: [AArch64] Add missing vrnd intrinsics

dmgreen added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:6309 + + def : Pat<(v1f64 (OpNode (v1f64 FPR64:$Rn))), + (!cast(NAME # Dr) FPR64:$Rn)>; I think the instructions in this multiclass are the vector variants. Can t

[PATCH] D158626: [AArch64] Add missing vrnd intrinsics

dmgreen added a comment. Other than where the pattern gets defined this looks OK to me. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:6309 + + def : Pat<(v1f64 (OpNode (v1f64 FPR64:$Rn))), + (!cast(NAME # Dr) FPR64:$Rn)>; miyengar wrote:

[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

dmgreen added inline comments. Comment at: llvm/include/llvm/Support/AArch64TargetParser.h:79 + AEK_SMEF16F16 = 1ULL << 47, // FEAT_SMEF16F16 + AEK_CSSC =1ULL << 49, // FEAT_CSSC }; 48!? Comment at: llvm/lib/Target/AArch64/AArch64.

<    1   2   3   4   >