aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/Support/TargetParserTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-12-20[Support] Move TargetParsers to new componentArchibald Elliott1-1787/+0
This is a fairly large changeset, but it can be broken into a few pieces: - `llvm/Support/*TargetParser*` are all moved from the LLVM Support component into a new LLVM Component called "TargetParser". This potentially enables using tablegen to maintain this information, as is shown in https://reviews.llvm.org/D137517. This cannot currently be done, as llvm-tblgen relies on LLVM's Support component. - This also moves two files from Support which use and depend on information in the TargetParser: - `llvm/Support/Host.{h,cpp}` which contains functions for inspecting the current Host machine for info about it, primarily to support getting the host triple, but also for `-mcpu=native` support in e.g. Clang. This is fairly tightly intertwined with the information in `X86TargetParser.h`, so keeping them in the same component makes sense. - `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains the target triple parser and representation. This is very intertwined with the Arm target parser, because the arm architecture version appears in canonical triples on arm platforms. - I moved the relevant unittests to their own directory. And so, we end up with a single component that has all the information about the following, which to me seems like a unified component: - Triples that LLVM Knows about - Architecture names and CPUs that LLVM knows about - CPU detection logic for LLVM Given this, I have also moved `RISCVISAInfo.h` into this component, as it seems to me to be part of that same set of functionality. If you get link errors in your components after this patch, you likely need to add TargetParser into LLVM_LINK_COMPONENTS in CMake. Differential Revision: https://reviews.llvm.org/D137838
2022-12-16[AArch64] RASv2 Assembly SupportArchibald Elliott1-1/+2
This feature adds upstream support for FEAT_RASv2 and FEAT_PFAR. Both are system-register-only, but FEAT_RAS is behind the command-line extension "+ras", so FEAT_RASv2 is behind "+rasv2". This patch includes support for ID_AA64MMFR4_EL1. This is an ID system register so it is not behind any feature flags. Differential Revision: https://reviews.llvm.org/D139936
2022-12-08[Arm][AArch64] Add support for v8.9-A/v9.4-A base extensionsLucas Prates1-1/+3
This implements the base extensions that are part of the v8.9-A and v9.4-A architecture versions, including: * The Clear BHB Instruction (FEAT_CLRBHB) * The Speculation Restriction Instruction (FEAT_SPECRES2) * The SLC target for the PRFM instruction * New system registers: * ID_AA64PFR2_EL1 * ID_AA64MMFR3_EL1 * HFGITR2_EL2 * SCTLR2_EL3 More information on the new extensions can be found on: * https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022 * https://developer.arm.com/downloads/-/exploration-tools Contributors: Sam Elliott, Tomas Matheson and Son Tuan Vu. Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D139424
2022-12-05Revert "[AArch64] Improve TargetParser API"Tomas Matheson1-148/+178
This reverts commit e83f1502f1be7a2a3b9a33f5a73867767e78ba6b. Did not build with C++20 and caused problems with dynamic libs.
2022-12-01[AArch64] Improve TargetParser APITomas Matheson1-178/+148
Re-land with constexpr StringRef::substr(): The TargetParser depends heavily on a collection of macros and enums to tie together information about architectures, CPUs and extensions. Over time this has led to some pretty awkward API choices. For example, recently a custom operator-- has been added to the enum, which effectively turns iteration into a graph traversal and makes the ordering of the macro calls in the header significant. More generally there is a lot of string <-> enum conversion going on. I think this shows the extent to which the current data structures are constraining us, and the need for a rethink. Key changes: - Get rid of Arch enum, which is used to bind fields together. Instead of passing around ArchKind, use the named ArchInfo objects directly or via references. - The list of all known ArchInfo becomes an array of pointers. - ArchKind::operator-- is replaced with ArchInfo::implies(), which defines which architectures are predecessors to each other. This allows features from predecessor architectures to be added in a more intuitive way. - Free functions of the form f(ArchKind) are converted to ArchInfo::f(). Some functions become unnecessary and are deleted. - Version number and profile are added to the ArchInfo. This makes comparison of architectures easier and moves a couple of functions out of clang and into AArch64TargetParser. - clang::AArch64TargetInfo ArchInfo is initialised to Armv8a not INVALID. - AArch64::ArchProfile which is distinct from ARM::ArchProfile - Give things sensible names and add some comments. Differential Revision: https://reviews.llvm.org/D138792
2022-12-01Revert "[AArch64] Improve TargetParser API"Tomas Matheson1-131/+161
Buildbots unhappy about constexpr function. This reverts commit 450de8008bb0ccb5dfc9dd69b6f5b434158772bd.
2022-12-01[AArch64] Improve TargetParser APITomas Matheson1-161/+131
The TargetParser depends heavily on a collection of macros and enums to tie together information about architectures, CPUs and extensions. Over time this has led to some pretty awkward API choices. For example, recently a custom operator-- has been added to the enum, which effectively turns iteration into a graph traversal and makes the ordering of the macro calls in the header significant. More generally there is a lot of string <-> enum conversion going on. I think this shows the extent to which the current data structures are constraining us, and the need for a rethink. Key changes: - Get rid of Arch enum, which is used to bind fields together. Instead of passing around ArchKind, use the named ArchInfo objects directly or via references. - The list of all known ArchInfo becomes an array of pointers. - ArchKind::operator-- is replaced with ArchInfo::implies(), which defines which architectures are predecessors to each other. This allows features from predecessor architectures to be added in a more intuitive way. - Free functions of the form f(ArchKind) are converted to ArchInfo::f(). Some functions become unnecessary and are deleted. - Version number and profile are added to the ArchInfo. This makes comparison of architectures easier and moves a couple of functions out of clang and into AArch64TargetParser. - clang::AArch64TargetInfo ArchInfo is initialised to Armv8a not INVALID. - AArch64::ArchProfile which is distinct from ARM::ArchProfile - Give things sensible names and add some comments. Differential Revision: https://reviews.llvm.org/D138792
2022-12-01[AArch64TargetParser] getArchFeatures -> getArchFeatureTomas Matheson1-8/+17
Differential Revision: https://reviews.llvm.org/D138753
2022-11-30[AArch64] Assembly support for VMSATomas Matheson1-15/+20
Virtual Memory System Architecture (VMSA) This is part of the 2022 A-Profile Architecture extensions and adds support for the following: - Translation Hardening Extension (FEAT_THE) - 128-bit Page Table Descriptors (FEAT_D128) - 56-bit Virtual Address (FEAT_LVA3) - Support for 128-bit System Registers (FEAT_SYSREG128) - System Instructions that can take 128-bit inputs (FEAT_SYSINSTR128) - 128-bit Atomic Instructions (FEAT_LSE128) - Permission Indirection Extension (FEAT_S1PIE, FEAT_S2PIE) - Permission Overlay Extension (FEAT_S1POE, FEAT_S2POE) - Memory Attribute Index Enhancement (FEAT_AIE) New instructions added: - FEAT_SYSREG128 adds MRRS and MSRR. - FEAT_SYSINSTR128 adds the SYSP instruction and TLBIP aliases. - FEAT_LSE128 adds LDCLRP, LDSET, and SWPP instructions. - FEAT_THE adds the set of RCW* instructions. Specs for individual instructions can be found here: https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/ Contributors: Keith Walker Lucas Prates Sam Elliott Son Tuan Vu Tomas Matheson Differential Revision: https://reviews.llvm.org/D138920
2022-11-25[AArch64] Assembly support for FEAT_LRCPC3Tomas Matheson1-1/+3
This patch implements assembly support for the 2022 A-Profile Architecture extension FEAT_LRCPC3. FEAT_LRCPC3 is AArch64 only and introduces new variants of load/store instructions with release consistency ordering. Specs for individual instructions can be found here: https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/ This feature is optionally available from v8.2a and therefore not enabled by default. Contributors: Lucas Prates Sam Elliot Son Tuan Vu Tomas Matheson Differential Revision: https://reviews.llvm.org/D138579
2022-11-22[AArch64][clang] implement 2022 General Data-Processing instructionsTies Stuij1-1/+2
This patch implements the 2022 Architecture General Data-Processing Instructions They include: Common Short Sequence Compression (CSSC) instructions - scalar comparison instructions SMAX, SMIN, UMAX, UMIN (32/64 bits) with or without immediate - ABS (absolute), CNT (count non-zero bits), CTZ (count trailing zeroes) - command-line options for CSSC Associated with these instructions in the documentation is the Range Prefetch Memory (RPRFM) instruction, which signals to the memory system that data memory accesses from a specified range of addresses are likely to occur in the near future. The instruction lies in hint space, and is made unconditional. Specs for the individual instructions can be found here: https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/ contributors to this patch: - Cullen Rhodes - Son Tuan Vu - Mark Murray - Tomas Matheson - Sam Elliott - Ties Stuij Reviewed By: lenary Differential Revision: https://reviews.llvm.org/D138488
2022-11-17[ARM][AArch64] Use StringRef in TargetParser structsTomas Matheson1-3/+2
The invalid case is now represented by an empty StringRef rather than a nullptr. Previously ARCH_FEATURE was build from SUB_ARCH by prepending "+". This is now reverse, so that the "+arch-feature" is now visible in the .def, which is a bit clearer. This meant converting one StringSwitch into a loop. Removed getters which are now mostly unnecessary. Removed some old FIXMEs. Differential Revision: https://reviews.llvm.org/D138026
2022-11-16[AArch64][ARM] add Armv8.9-a/Armv9.4-a identifier supportTies Stuij1-4/+20
For both ARM and AArch64 add support for specifying -march=armv8.9a/armv9.4a to clang. Add backend plumbing like target parser and predicate support. For a summary of Amv8.9/Armv9.4 features, see: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022 For detailed information, consult the Arm Architecture Reference Manual for A-profile architecture: https://developer.arm.com/documentation/ddi0487/latest/ People who contributed to this patch: - Keith Walker - Ties Stuij Reviewed By: tmatheson Differential Revision: https://reviews.llvm.org/D138010
2022-11-15[TargetParser] Split AArch64TargetParser from ARMTargetParserTomas Matheson1-9/+2
AArch64TargetParser reuses data structures and some data from ARMTargetParser, which causes more problems than it solves. This change separates them. Code which is common to ARM and AArch64 is moved to ARMTargetParserCommon which both ARMTargetParser and AArch64TargetParser use. Some of the information in AArch64TargetParser.def was unused or nonsensical (CPU_ATTR, ARCH_ATTR, ARCH_FPU) because it reused data strutures from ARMTargetParser where some of these make sense. These are removed. Differential Revision: https://reviews.llvm.org/D137924
2022-11-14[AArch64] Add all SME2.1 instructions Assembly/DisassemblyCaroline Concatto1-1/+3
This patch adds a new feature flag: sme-f16f16 to represent FEAT_SME-F16F16 This patch add the following instructions: SME2.1 stand alone instructions: MOVAZ (array to vector, four registers): Move and zero four ZA single-vector groups to vector registers. (array to vector, two registers): Move and zero two ZA single-vector groups to vector registers. (tile to vector, four registers): Move and zero four ZA tile slices to vector registers. (tile to vector, single): Move and zero ZA tile slice to vector register. (tile to vector, two registers): Move and zero two ZA tile slices to vector registers. LUTI2 (Strided four registers): Lookup table read with 2-bit indexes. (Strided two registers): Lookup table read with 2-bit indexes. LUTI4 (Strided four registers): Lookup table read with 4-bit indexes. (Strided two registers): Lookup table read with 4-bit indexes. ZERO (double-vector): Zero ZA double-vector groups. (quad-vector): Zero ZA quad-vector groups. (single-vector): Zero ZA single-vector groups. SME2p1 and SME-F16F16: All instructions are half precision elements: FADD: Floating-point add multi-vector to ZA array vector accumulators. FSUB: Floating-point subtract multi-vector from ZA array vector accumulators. FMLA (multiple and indexed vector): Multi-vector floating-point fused multiply-add by indexed element. (multiple and single vector): Multi-vector floating-point fused multiply-add by vector. (multiple vectors): Multi-vector floating-point fused multiply-add. FMLS (multiple and indexed vector): Multi-vector floating-point fused multiply-subtract by indexed element. (multiple and single vector): Multi-vector floating-point fused multiply-subtract by vector. (multiple vectors): Multi-vector floating-point fused multiply-subtract. FCVT (widening): Multi-vector floating-point convert from half-precision to single-precision (in-order). FCVTL: Multi-vector floating-point convert from half-precision to deinterleaved single-precision. FMOPA (non-widening): Floating-point outer product and accumulate. FMOPS (non-widening): Floating-point outer product and subtract. SME2p1 and B16B16: BFADD: BFloat16 floating-point add multi-vector to ZA array vector accumulators. BFSUB: BFloat16 floating-point subtract multi-vector from ZA array vector accumulators. BFCLAMP: Multi-vector BFloat16 floating-point clamp to minimum/maximum number. BFMLA (multiple and indexed vector): Multi-vector BFloat16 floating-point fused multiply-add by indexed element. (multiple and single vector): Multi-vector BFloat16 floating-point fused multiply-add by vector. (multiple vectors): Multi-vector BFloat16 floating-point fused multiply-add. BFMLS (multiple and indexed vector): Multi-vector BFloat16 floating-point fused multiply-subtract by indexed element. (multiple and single vector): Multi-vector BFloat16 floating-point fused multiply-subtract by vector. (multiple vectors): Multi-vector BFloat16 floating-point fused multiply-subtract. BFMAX (multiple and single vector): Multi-vector BFloat16 floating-point maximum by vector. (multiple vectors): Multi-vector BFloat16 floating-point maximum. BFMAXNM (multiple and single vector): Multi-vector BFloat16 floating-point maximum number by vector. (multiple vectors): Multi-vector BFloat16 floating-point maximum number. BFMIN (multiple and single vector): Multi-vector BFloat16 floating-point minimum by vector. (multiple vectors): Multi-vector BFloat16 floating-point minimum. BFMINNM (multiple and single vector): Multi-vector BFloat16 floating-point minimum number by vector. (multiple vectors): Multi-vector BFloat16 floating-point minimum number. BFMOPA (non-widening): BFloat16 floating-point outer product and accumulate. BFMOPS (non-widening): BFloat16 floating-point outer product and subtract. The reference can be found here: https://developer.arm.com/documentation/ddi0602/2022-09 Differential Revision: https://reviews.llvm.org/D137571
2022-11-09[ARM] Move Triple::getARMCPUForArch into ARMTargetParserTomas Matheson1-1/+66
This is very backend specific so either belongs in Toolchains/ARM or in ARMTargetParser. Since it is used in lldb, ARMTargetParser made more sense. This is part of an effort to move information about ARM/AArch64 architecture versions, extensions and CPUs into their respective TargetParsers. Differential Revision: https://reviews.llvm.org/D137564
2022-11-09[AArch64] Add support for the Cortex-X3 CPUVictor Campos1-1/+14
Cortex-X3 is an Armv9-A AArch64 CPU. This patch introduces support for Cortex-X3. Technical Reference Manual: https://developer.arm.com/documentation/101593/latest Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D136589
2022-11-07[AArch64][SVE2] Add the SVE2.1 BF16 instructionsDavid Sherwood1-1/+4
This patch adds the new FEAT_B16B16 feature as well as the assembly/disassembly for all of the B16B16 instructions: bfadd: BFloat16 floating-point add vectors bfsub: BFloat16 floating-point subtract vectors bfmul: BFloat16 floating-point multiply vectors bfclamp: BFloat16 floating-point clamp to minimum/maximum number bfmax: BFloat16 floating-point maximum bfmaxnm: BFloat16 floating-point maximum number bfmin: BFloat16 floating-point minimum bfminnm: BFloat16 floating-point minimum number bfmla: BFloat16 floating-point fused multiply-add vectors bfmls: BFloat16 floating-point fused multiply-subtract vectors The reference can be found here: https://developer.arm.com/documentation/ddi0602/2022-09 Differential Revision: https://reviews.llvm.org/D137321
2022-11-07[AArch64] Add SME2.1 target feature for Armv9-A 2022 Architecture ExtensionDavid Sherwood1-1/+3
First patch in a series adding MC layer support for SME2.1. This patch adds the following feature: sme2p1 The reference can be found here: https://developer.arm.com/documentation/ddi0602/2022-09 Differential Revision: https://reviews.llvm.org/D137410
2022-11-03[AArch64] Add support for the Cortex-A715 CPUSimi Pallipurath1-1/+14
Cortex-A715 is an Armv9-A AArch64 CPU. This patch introduces support for Cortex-A715. Technical Reference Manual: https://developer.arm.com/documentation/101590/latest. Reviewed By: vhscampos Differential Revision: https://reviews.llvm.org/D136957
2022-10-25[Clang][AArch64] Add TargetParser support for defining CPU aliasesSjoerd Meijer1-1/+2
This adds AArch64 TargetParser support to define CPU aliases, and ports the definition of Grace over to that. This is following up on D136425. Differential Revision: https://reviews.llvm.org/D136611
2022-10-21[AArch64] Add SVE2.1 target feature for Armv9-A 2022 Architecture ExtensionDavid Sherwood1-1/+3
First patch in a series adding MC layer support for SVE2.1. This patch adds the following feature: sve2p1 Some of the existing SVE instructions added for SME are now also available under the sve2p1 feature, which are now guarded by the HasSVE2p1orSME predicate. The reference can be found here: https://developer.arm.com/documentation/ddi0602/2022-09 Differential Revision: https://reviews.llvm.org/D136352
2022-10-19[AArch64] Replace sme-i64 by sme-i16i64 and sme-f64 by sme-f64f64Caroline Concatto1-5/+5
The names in developer.arm for these SME features are: HaveSMEI16I64 and HaveSMEF64F64 so the new flag names are consistent with the documentation page Reviewed By: sdesmalen, c-rhodes Differential Revision: https://reviews.llvm.org/D135974
2022-10-13[AArch64] Add SME 2 target feature for Armv8-A and Armv9-A 2022 Architecture ↵Caroline Concatto1-1/+4
Extension First patch in a series adding MC layer support for Scalable Matrix Extension 2 (SME2). This patch adds the following feature: sme2 The 2022 Architecture Extension release adds other feature flags(eg.:sme2.1), that will be in follow-up patches. The reference can be found here: https://developer.arm.com/documentation/ddi0602/2022-09 Differential Revision: https://reviews.llvm.org/D135448
2022-09-27[AArch64] Add all predecessor archs in target infoDaniel Kiss1-0/+21
A given function is compatible with all previous arch versions. To avoid compering values of the attribute this logic adds all predecessor architecture values. Reviewed By: dmgreen, DavidSpickett Differential Revision: https://reviews.llvm.org/D134353
2022-09-27[AArch64] Add Neoverse V2 CPU supportDavid Sherwood1-1/+12
Adds support for the Neoverse V2 CPU to the AArch64 backend. Differential Revision: https://reviews.llvm.org/D134352
2022-09-23[Arm][AArch64] Make getArchFeatures to use TargetParser.defDaniel Kiss1-2/+2
Prefixing the the SubArch with plus sign makes the ArchFeature name. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D134349
2022-09-22AArch64: add support for newer Apple CPUsTim Northover1-1/+28
They're roughly ARMv8.6. This works in the .td file, but in AArch64TargetParser.def, marking them v8.6 brings in support for the SM4 cryptographic hash and we don't actually have that. So TargetParser side they're marked as v8.5, with the extra features (BF16 and I8MM added manually). Finally, A16 supports the HCX extension in addition to v8.6. This has no TargetParser implications.
2022-09-08[llvm] Use std::size instead of llvm::array_lengthofJoe Loser1-6/+6
LLVM contains a helpful function for getting the size of a C-style array: `llvm::array_lengthof`. This is useful prior to C++17, but not as helpful for C++17 or later: `std::size` already has support for C-style arrays. Change call sites to use `std::size` instead. Differential Revision: https://reviews.llvm.org/D133429
2022-09-08[LLVM][ARM] Remove options for armv2, 2A, 3 and 3MDavid Spickett1-27/+14
Fixes #57486 These pre v4 architectures are not specifically supported by codegen. As demonstrated in the linked issue. GCC has not supported 3M since GCC 9 and presumably 2 and 2A earlier than that. So we are aligned in that sense. (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2abd6e34fcf3bd9f9ffafcaa47cdc3ed443f9add) This removes the options and associated testing. The Pre_v4 build attribute remains mainly because its absence would be more confusing. It will not be used other than to complete the list of build attributes as shown in the ABI. https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst#3352the-target-related-attributes Reviewed By: nickdesaulniers, peter.smith, rengolin Differential Revision: https://reviews.llvm.org/D133109
2022-07-05[ARM] Add Support for Cortex-M85Archibald Elliott1-1/+7
This patch adds support for Arm's Cortex-M85 CPU. The Cortex-M85 CPU is an Arm v8.1m Mainline CPU, with optional support for MVE and PACBTI, both of which are enabled by default. Parts have been coauthored by by Mark Murray, Alexandros Lamprineas and David Green. Differential Revision: https://reviews.llvm.org/D128415
2022-05-09[AArch64] Ampere1 does not support MTEPhilipp Tomsich1-1/+1
The initial support for the Ampere1 mistakenly signalled support for the MTE feature. However, the core does not include the optional MTE functionality. Update the target parser to not include MTE for Ampere1. Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D125191
2022-05-03[AArch64] Support for Ampere1 corePhilipp Tomsich1-1/+9
Add support for the Ampere Computing Ampere1 core. Ampere1 implements the AArch64 state and is compatible with ARMv8.6-A. Differential Revision: https://reviews.llvm.org/D117112
2022-04-28[ARM] add Armv9 build attributeTies Stuij1-3/+6
The build attribute number can be found in the Arm ABI addenda32 document: https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst#335target-related-attributes Reviewed By: tmatheson Differential Revision: https://reviews.llvm.org/D124090
2022-04-11[llvm][AArch64] Generate getExtensionFeatures from the list of extensionsDavid Spickett1-13/+51
This takes the AARCH64_ARCH_EXT_NAME in AArch64TargetParser.def and uses it to generate all the "if bit is set add this feature name" code. Which gives us a bunch that we were missing. I've updated testing to include those and reordered them to match the order in the .def. The final part of the test will catch any missing extensions if we somehow manage to not generate an if block for them. This has changed the order of cc1's "-target-feature" output so I've updated some tests in clang to reflect that. Reviewed By: tmatheson Differential Revision: https://reviews.llvm.org/D123296
2022-03-30[AArch64] Fix AArch64TargetParser.def to match AArch64.td.Eli Friedman1-22/+25
Currently, we have two different lists of features each CPU supports... and those lists aren't consistent. This patch assumes AArch64.td is right, and tries to fix AArch64TargetParser to match. It's hard to find documentation for the right features, but reviewers have confirmed these changes. Probably we should try to unify the two lists at some point, but synchronizing them seems like a prerequisite to that anyway. Differential Revision: https://reviews.llvm.org/D122274
2022-01-31[ARM] Add Cortex-X1C Support for Clang and LLVMTies Stuij1-3/+17
This patch upstreams support for the Arm-v8 Cortex-X1C processor for AArch64 and ARM. For more information, see: - https://community.arm.com/arm-community-blogs/b/announcements/posts/arm-cortex-x1c - https://developer.arm.com/documentation/101968/0002/Functional-description/Technical-overview/Components The following people contributed to this patch: - Simon Tatham - Ties Stuij Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D117202
2022-01-26Revert "Rename llvm::array_lengthof into llvm::size to match std::size from ↵Benjamin Kramer1-6/+6
C++17" This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2. - It conflicts with the existing llvm::size in STLExtras, which will now never be called. - Calling it without llvm:: breaks C++17 compat
2022-01-26Rename llvm::array_lengthof into llvm::size to match std::size from C++17serge-sans-paille1-6/+6
As a conquence move llvm::array_lengthof from STLExtras.h to STLForwardCompat.h (which is included by STLExtras.h so no build breakage expected).
2022-01-21[NFCI][Support] Avoid ASSERT_/EXPECT_TRUE(A <op> B)Archibald Elliott1-11/+15
The error messages in tests are far better when a test fails if the test is written using ASSERT_/EXPECT_<operator>(A, B) rather than ASSERT_/EXPECT_TRUE(A <operator> B). This commit updates all of llvm/unittests/Support to use these macros where possible. This change has not been possible in: - llvm/unittests/Support/FSUniqueIDTest.cpp - due to not overloading operators beyond ==, != and <. - llvm/unittests/Support/BranchProbabilityTest.cpp - where the unchanged tests are of the operator overloads themselves. There are other possibilities of this conversion not being valid, which have not applied in these tests, as they do not use NULL (they use nullptr), and they do not use const char* (they use std::string or StringRef). Reviewed By: mubashar_ Differential Revision: https://reviews.llvm.org/D117319
2022-01-21[llvm] Cleanup header dependencies in ADT and Supportserge-sans-paille1-1/+2
The cleanup was manual, but assisted by "include-what-you-use". It consists in 1. Removing unused forward declaration. No impact expected. 2. Removing unused headers in .cpp files. No impact expected. 3. Removing unused headers in .h files. This removes implicit dependencies and is generally considered a good thing, but this may break downstream builds. I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the modification in the second part of the commit. 4. Replacing header inclusion by forward declaration. This has the same impact as 3. Notable changes: - llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h - llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h - llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h - llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h You may need to add some of these headers in your compilation units, if needs be. As an hint to the impact of the cleanup, running clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l before: 8000919 lines after: 7917500 lines Reduced dependencies also helps incremental rebuilds and is more ccache friendly, something not shown by the above metric :-) Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
2022-01-17[Clang][AArch64][ARM] PMUv3 Option AddedMubashar Ahmad1-11/+10
An option has been added to Clang to enable or disable the PMU v3 architecture extension. Differential Revision: https://reviews.llvm.org/D116748
2022-01-15[AArch64] clang support for Armv8.8/9.3 MOPSLucas Prates1-0/+1
This introduces clang command line support for the new Armv8.8-A and Armv9.3-A instructions for standardising memcpy, memset and memmove operations, which was previously introduced into LLVM in https://reviews.llvm.org/D116157. Patch by Lucas Prates, Tomas Matheson and Son Tuan Vu. Differential Revision: https://reviews.llvm.org/D117271
2022-01-12clang support for Armv8.8/9.3 HBCTomas Matheson1-37/+35
This introduces clang command line support for new Armv8.8-A and Armv9.3-A Hinted Conditional Branches feature, previously introduced into LLVM in https://reviews.llvm.org/D116156. Patch by Tomas Matheson and Son Tuan Vu. Differential Revision: https://reviews.llvm.org/D116939
2022-01-11Revert "[Clang][AArch64][ARM] PMUv3.4 Option Added"David Green1-46/+49
It turns out this is conflating a few different PMU extensions. And on Arm ended up breaking M-Profile code generation. Reverting for the moment whilst we sort out the details. This reverts commit d17fb46e894501568a1bf3b11a5d920817444630.
2022-01-10[Clang][AArch64][ARM] PMUv3.4 Option AddedMubashar Ahmad1-49/+46
An option has been added to Clang to enable or disable the PMU v3.4 architecture extension. Differential Revision: https://reviews.llvm.org/D116748
2022-01-03[ARM][AArch64] Introduce Armv9.3-ALucas Prates1-0/+1
This patch introduces support for targetting the Armv9.3-A architecture, which should map to the existing Armv8.8-A extensions. Differential Revision: https://reviews.llvm.org/D116158
2021-12-31[ARM] Introduce an empty "armv8.8-a" architecture.Simon Tatham1-24/+31
This is the first commit in a series that implements support for "armv8.8-a" architecture. This should contain all the necessary boilerplate to make the 8.8-A architecture exist from LLVM and Clang's point of view: it adds the new arch as a subtarget feature, a definition in TargetParser, a name on the command line, an appropriate set of predefined macros, and adds appropriate tests. The new architecture name is supported in both AArch32 and AArch64. However, in this commit, no actual _functionality_ is added as part of the new architecture. If you specify -march=armv8.8a, the compiler will accept it and set the right predefines, but generate no code any differently. Differential Revision: https://reviews.llvm.org/D115694
2021-11-22[AArch64][ARM] Add missing SVE/SVE2 features from Cortex-A710Bradley Smith1-6/+6
Differential Revision: https://reviews.llvm.org/D114169
2021-11-18[Clang][SVE] Properly enable/disable dependant SVE target features based ↵Bradley Smith1-11/+11
upon +(no)sve.* options Co-authored-by: Graham Hunter <graham.hunter@arm.com> Differential Revision: https://reviews.llvm.org/D113776
generated by cgit v1.1 at 2025-10-29 01:43:54 +0000