aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/TargetParser.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-12-20[Support] Move TargetParsers to new componentArchibald Elliott1-339/+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-11-25[ARM] Move ARM::parseBranchProtection into ARMTargetParserCommonArchibald Elliott1-48/+0
This should live with the Arm targets, given they have target-specific target parsers. Differential Revision: https://reviews.llvm.org/D137835
2022-08-18[RISCV] Change how mtune aliases are implemented.Craig Topper1-10/+4
The previous implementation translated from names like sifive-7-series to sifive-7-rv32 or sifive-7-rv64. This also required sifive-7-rv32 and sifive-7-rv64 to be valid CPU names. As those are not real CPUs it doesn't make sense to accept them in -mcpu. This patch does away with the translation and adds sifive-7-series directly to RISCV.td. Removing sifive-7-rv32 and sifive-7-rv64. sifive-7-series is only allowed in -mtune. I've also added "rocket" to RISCV.td but have not removed rocket-rv32 or rocket-rv64. To prevent -mcpu=sifive-7-series or -mcpu=rocket being used with llc, I've added a Feature32Bit to all rv32 CPUs. And made it an error to have an rv32 triple without Feature32Bit. sifive-7-series and rocket do not have Feature32Bit or Feature64Bit set so the user would need to provide -mattr=+32bit or -mattr=+64bit along with the -mcpu to avoid the error. SiFive no longer names their newer products with 3, 5, or 7 series. Instead we have p200 series, x200 series, p500 series, and p600 series. Following the previous behavior would require a sifive-p500-rv32 and sifive-p500-rv64 in order to support -mtune=sifive-p500-series. There is currently no p500 product, but it could start getting confusing if there was in the future. I'm open to hearing alternatives for how to achieve my main goal of removing sifive-7-rv32/rv64 as a CPU name. Reviewed By: reames Differential Revision: https://reviews.llvm.org/D131708
2022-08-10[RISCV] Rename PROC_ALIAS to TUNE_ALIAS to reflect it's usage. NFCCraig Topper1-2/+2
This is not used as general CPU alias. Only to support -mtune. Name it as such. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D131602
2022-04-29[AMDGPU] Add gfx11 subtarget ELF definitionJoe Nash1-0/+8
This is the first patch of a series to upstream support for the new subtarget. Contributors: Jay Foad <jay.foad@amd.com> Konstantin Zhuravlyov <kzhuravl_dev@outlook.com> Patch 1/N for upstreaming AMDGPU gfx11 architectures. Reviewed By: foad, kzhuravl, #amdgpu Differential Revision: https://reviews.llvm.org/D124536
2022-03-02[AMDGPU] Add gfx1036 targetAakanksha1-0/+2
Differential Revision: https://reviews.llvm.org/D120846
2022-03-02[AMDGPU] Add gfx940 targetStanislav Mekhanoshin1-0/+2
This is target definition only. Differential Revision: https://reviews.llvm.org/D120688
2022-02-08[RISCV][NFC] Refactor RISCVISAInfo.Zakk Chen1-15/+0
1. Remove computeDefaultABIFromArch and add computeDefaultABI in RISCVISAInfo. 2. Add parseFeatureBits which may used in D118333. Differential Revision: https://reviews.llvm.org/D119250
2022-01-26[NFC] Additional header dependency cleanup LLVMSupportserge-sans-paille1-1/+1
A few more forward-declarations, a few less headers. the impact on number of preprocessed lines for LLVMSupport is negligible (-3K lines) but it's always good to remove dependencies. Related discourse thread: https://llvm.discourse.group/t/include-what-you-use-include-cleanup
2022-01-21[llvm] Cleanup header dependencies in ADT and Supportserge-sans-paille1-2/+0
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
2021-12-10[RISCV][Clang] Compute the default target-abi if it's empty.Zakk Chen1-0/+15
Every generated IR has a corresponding target-abi value, so encoding a non-empty value would improve the robustness and correctness. Reviewed By: asb, jrtc27, arichardson Differential Revision: https://reviews.llvm.org/D105555
2021-12-01[clang][ARM] PACBTI-M frontend supportTies Stuij1-0/+48
Handle branch protection option on the commandline as well as a function attribute. One patch for both mechanisms, as they use the same underlying parsing mechanism. These are recorded in a set of LLVM IR module-level attributes like we do for AArch64 PAC/BTI (see https://reviews.llvm.org/D85649): - command-line options are "translated" to module-level LLVM IR attributes (metadata). - functions have PAC/BTI specific attributes iff the __attribute__((target("branch-protection=...))) was used in the function declaration. - command-line option -mbranch-protection to armclang targeting Arm, following this grammar: branch-protection ::= "-mbranch-protection=" <protection> protection ::= "none" | "standard" | "bti" [ "+" <pac-ret-clause> ] | <pac-ret-clause> [ "+" "bti"] pac-ret-clause ::= "pac-ret" [ "+" <pac-ret-option> ] pac-ret-option ::= "leaf" ["+" "b-key"] | "b-key" ["+" "leaf"] b-key is simply a placeholder to make it consistent with AArch64's version. In Arm, however, it triggers a warning informing that b-key is unsupported and a-key will be selected instead. - Handle _attribute_((target(("branch-protection=..."))) for AArch32 with the same grammer as the commandline options. This patch is part of a series that adds support for the PACBTI-M extension of the Armv8.1-M architecture, as detailed here: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension The PACBTI-M specification can be found in the Armv8-M Architecture Reference Manual: https://developer.arm.com/documentation/ddi0553/latest The following people contributed to this patch: - Momchil Velikov - Victor Campos - Ties Stuij Reviewed By: vhscampos Differential Revision: https://reviews.llvm.org/D112421
2021-06-24[AMDGPU] Add gfx1035 targetAakanksha Patil1-0/+2
Differential Revision: https://reviews.llvm.org/D104804
2021-06-08Reland "[AMDGPU] Add gfx1013 target"Brendon Cahoon1-0/+2
This reverts commit 211e584fa2a4c032e4d573e7cdbffd622aad0a8f. Fixed a use-after-free error that caused the sanitizers to fail.
2021-06-08Revert "[AMDGPU] Add gfx1013 target"Brendon Cahoon1-2/+0
This reverts commit ea10a86984ea73fcec3b12d22404a15f2f59b219. A sanitizer buildbot reports an error.
2021-06-08[AMDGPU] Add gfx1013 targetBrendon Cahoon1-0/+2
Differential Revision: https://reviews.llvm.org/D103663
2021-05-13[AMDGPU] Add gfx1034 targetAakanksha Patil1-0/+2
Differential Revision: https://reviews.llvm.org/D102306
2021-04-16[AMDGPU] Enforce that gfx802/803/805 do not support XNACKTony1-9/+9
Reviewed By: kzhuravl Differential Revision: https://reviews.llvm.org/D100679
2021-02-17[AMDGPU] gfx90a supportStanislav Mekhanoshin1-0/+2
Differential Revision: https://reviews.llvm.org/D96906
2021-01-05[llvm] Use llvm::lower_bound and llvm::upper_bound (NFC)Kazu Hirata1-4/+4
2020-12-07[clang][AMDGPU] rename sram-ecc as srameccYaxun (Sam) Liu1-2/+2
As backend renamed sram-ecc to sramecc, this patch makes corresponding change in clang. Differential Revision: https://reviews.llvm.org/D86217
2020-11-03[AMDGPU] Add gfx1033 targetTim Renouf1-0/+2
Differential Revision: https://reviews.llvm.org/D90447 Change-Id: If2650fc7f31bbdd49c76e74a9ca8e3734d769761
2020-11-03[AMDGPU] Add gfx90c targetTim Renouf1-0/+2
This differentiates the Ryzen 4000/4300/4500/4700 series APUs that were previously included in gfx909. Differential Revision: https://reviews.llvm.org/D90419 Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-10-16[AMDGPU] Drop array size in AMDGCNGPUs and R600GPUsStanislav Mekhanoshin1-2/+2
Differential Revision: https://reviews.llvm.org/D89568
2020-10-16[RISCV] Add -mtune supportKito Cheng1-0/+31
- The goal of this patch is improve option compatible with RISCV-V GCC, -mcpu support on GCC side will sent patch in next few days. - -mtune only affect the pipeline model and non-arch/extension related target feature, e.g. instruction fusion; in td file it called TuneFeatures, which is introduced by X86 back-end[1]. - -mtune accept all valid option for -mcpu and extra alias processor option, e.g. `generic`, `rocket` and `sifive-7-series`, the purpose is option compatible with RISCV-V GCC. - Processor alias for -mtune will resolve according the current target arch, rv32 or rv64, e.g. `rocket` will resolve to `rocket-rv32` or `rocket-rv64`. - Interaction between -mcpu and -mtune: * -mtune has higher priority than -mcpu for pipeline model and TuneFeatures. [1] https://reviews.llvm.org/D85165 Reviewed By: luismarques Differential Revision: https://reviews.llvm.org/D89025
2020-10-15[AMDGPU] gfx1032 targetStanislav Mekhanoshin1-1/+3
Differential Revision: https://reviews.llvm.org/D89487
2020-10-10[AMDGPU] Add gfx602, gfx705, gfx805 targetsTim Renouf1-3/+10
At AMD, in an internal audit of our code, we found some corner cases where we were not quite differentiating targets enough for some old hardware. This commit is part of fixing that by adding three new targets: * The "Oland" and "Hainan" variants of gfx601 are now split out into gfx602. LLPC (in the GPUOpen driver) and other front-ends could use that to avoid using the shaderZExport workaround on gfx602. * One variant of gfx703 is now split out into gfx705. LLPC and other front-ends could use that to avoid using the shaderSpiCsRegAllocFragmentation workaround on gfx705. * The "TongaPro" variant of gfx802 is now split out into gfx805. TongaPro has a faster 64-bit shift than its former friends in gfx802, and a subtarget feature could be set up for that to take advantage of it. This commit does not make that change; it just adds the target. V2: Add clang changes. Put TargetParser list in order. V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order, so fix the GPUKind order. Differential Revision: https://reviews.llvm.org/D88916 Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
2020-08-18[HIP] Support target id by --offload-archYaxun (Sam) Liu1-20/+29
This patch introduces support of target id by -offload-arch. Differential Revision: https://reviews.llvm.org/D60620
2020-08-05[AMDGPU] gfx1031 targetStanislav Mekhanoshin1-1/+3
Differential Revision: https://reviews.llvm.org/D85337
2020-07-16[RISCV] Add support for -mcpu option.Zakk Chen1-1/+63
Summary: 1. gcc uses `-march` and `-mtune` flag to chose arch and pipeline model, but clang does not have `-mtune` flag, we uses `-mcpu` to chose both infos. 2. Add SiFive e31 and u54 cpu which have default march and pipeline model. 3. Specific `-mcpu` with rocket-rv[32|64] would select pipeline model only, and use the driver's arch choosing logic to get default arch. Reviewers: lenary, asb, evandro, HsiangKai Reviewed By: lenary, asb, evandro Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D71124
2020-06-15[AMDGPU] Add gfx1030 targetStanislav Mekhanoshin1-1/+3
Differential Revision: https://reviews.llvm.org/D81886
2020-04-10AMDGPU: Teach toolchain to link rocm device libsMatt Arsenault1-3/+3
Currently the library is separately linked, but this isn't correct to implement fast math flags correctly. Each module should get the version of the library appropriate for its combination of fast math and related flags, with the attributes propagated into its functions and internalized. HIP already maintains the list of libraries, but this is not used for OpenCL. Unfortunately, HIP uses a separate --hip-device-lib argument, despite both languages using the same bitcode library. Eventually these two searches need to be merged. An additional problem is there are 3 different locations the libraries are installed, depending on which build is used. This also needs to be consolidated (or at least the search logic needs to deal with this unnecessary complexity).
2020-01-01[NFC] Fixes -Wrange-loop-analysis warningsMark de Wever1-4/+4
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857
2019-07-09[AMDGPU] gfx908 targetStanislav Mekhanoshin1-1/+3
Differential Revision: https://reviews.llvm.org/D64429 llvm-svn: 365525
2019-06-14[AMDGPU] gfx1011/gfx1012 targetsStanislav Mekhanoshin1-1/+5
Differential Revision: https://reviews.llvm.org/D63307 llvm-svn: 363344
2019-04-24[AMDGPU] Add gfx1010 target definitionsStanislav Mekhanoshin1-18/+20
Differential Revision: https://reviews.llvm.org/D61041 llvm-svn: 359113
2019-03-17AMDGPU: Partially fix default device for HSAMatt Arsenault1-4/+6
There are a few different issues, mostly stemming from using generation based checks for anything instead of subtarget features. Stop adding flat-address-space as a feature for HSA, as it should only be a device property. This was incorrectly allowing flat instructions to select for SI. Increase the default generation for HSA to avoid the encoding error when emitting objects. This has some other side effects from various checks which probably should be separate subtarget features (in the cost model and for dealing with the DS offset folding issue). Partial fix for bug 41070. It should probably be an error to try using amdhsa without flat support. llvm-svn: 356347
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-11-28Fix build error due to missing cctype includeDavid Spickett1-1/+0
in ARMTargetParser.cpp. llvm-svn: 347762
2018-11-28[ARM, AArch64] Move ARM/AArch64 target parsers intoDavid Spickett1-931/+0
separate files to enable future changes. This moves ARM and AArch64 target parsing into their own files. They are still accessible through TargetParser.h as before. Several functions in AArch64 which were just forwarders to ARM have been removed. All except AArch64::getFPUName were unused, and that was only used in a test. Which itself was overlapping one in ARM, so it has also been removed. Differential revision: https://reviews.llvm.org/D53980 llvm-svn: 347741
2018-10-24[AMDGPU] Defined gfx909 Raven Ridge 2Tim Renouf1-1/+3
Differential Revision: https://reviews.llvm.org/D53418 Change-Id: Ie3d054f2e956c2768988c0f4c0ffd29a47294eef llvm-svn: 345120
2018-09-26[ARM/AArch64][v8.5A] Add Armv8.5-A targetOliver Stannard1-0/+5
This patch allows targeting Armv8.5-A, adding the architecture to tablegen and setting the options to be identical to Armv8.4-A for the time being. Subsequent patches will add support for the different features included in the Armv8.5-A Reference Manual. Patch by Pablo Barrio! Differential revision: https://reviews.llvm.org/D52470 llvm-svn: 343102
2018-09-12AMDGPU: Re-apply r341982 after fixing the layering issueKonstantin Zhuravlyov1-10/+40
Move isa version determination into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). llvm-svn: 342069
2018-09-12Revert "AMDGPU: Move isa version and EF_AMDGPU_MACH_* determination into ↵Ilya Biryukov1-128/+10
TargetParser." This reverts commit r341982. The change introduced a layering violation. Reverting to unbreak our integrate. llvm-svn: 342023
2018-09-11AMDGPU: Move isa version and EF_AMDGPU_MACH_* determinationKonstantin Zhuravlyov1-10/+128
into TargetParser. Also switch away from target features to CPU string when determining isa version. This fixes an issue when we output wrong isa version in the object code when features of a particular CPU are altered (i.e. gfx902 w/o xnack used to result in gfx900). Differential Revision: https://reviews.llvm.org/D51890 llvm-svn: 341982
2018-08-29Start reserving x18 by default on Android targets.Peter Collingbourne1-1/+2
Differential Revision: https://reviews.llvm.org/D45588 llvm-svn: 340889
2018-08-21Try to fix bot build failureMatt Arsenault1-1/+1
llvm-svn: 340296
2018-08-21AMDGPU: Partially move target handling code from clang to TargetParserMatt Arsenault1-0/+147
A future change in clang necessitates access of this information from the driver, so move this into a common place. Try to mimic something resembling the API the other targets are using here. One thing I'm uncertain about is how to split amdgcn and r600 handling. Here I've mostly duplicated the functions for each, while keeping the same enums. I think this is a bit awkward for the features which don't matter for amdgcn. It's also a bit messy that this isn't a complete set of subtarget features. This is just the minimum set needed for the driver code. For example building the list of subtarget feature names is still in clang. llvm-svn: 340291
2018-08-17[ARM/AArch64] Support FP16 +fp16fml instructionsBernard Ogden1-0/+7
Add +fp16fml feature for new FP16 instructions, which are a mandatory part of FP16 from v8.4-A and an optional part of FP16 from v8.2-A. It doesn't seem to be possible to model this in LLVM, but the relationship between the options is handled by the related clang patch. In keeping with what I think is the usual practice, the fp16fml extension is accepted regardless of base architecture version. Builds on/replaces Sjoerd Meijer's patch to add these instructions at https://reviews.llvm.org/D49839. Differential Revision: https://reviews.llvm.org/D50228 llvm-svn: 340013
2018-07-26[AArch64] Armv8.2-A: add the crypto extensionsSjoerd Meijer1-0/+11
This adds MC support for the crypto instructions that were made optional extensions in Armv8.2-A (AArch64 only). Differential Revision: https://reviews.llvm.org/D49370 llvm-svn: 338010
generated by cgit v1.1 at 2025-08-06 10:00:27 +0000