aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/ADT/TripleTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-12-20[Support] Move TargetParsers to new componentArchibald Elliott1-2144/+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-10[ADT][Triple] Add environment kinds for LoongArch GNU multiarch tuplesWANG Xuerui1-0/+60
The canonical multiarch tuples for LoongArch are defined in [the LoongArch toolchain conventions][1] document. As the musl port is still WIP, only the GNU triples are added for now. The spec mentions `loongarch64-linux-gnuf64`, which is functionally the same as the existing `loongarch64-linux-gnu` triple, only with the floating-point ABI part explicitly spelled out. Both forms are supported, but normalization of one into another is not implemented in this patch, to give the ecosystem some time to experiment and discuss. [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D135751
2022-11-09[ARM] Move Triple::getARMCPUForArch into ARMTargetParserTomas Matheson1-64/+0
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-09-29[ARM64EC] Add arm64ec for getArchNamechenglin.bi1-0/+10
Followup D125412, return the correct arch name for Arm64EC Reviewed By: efriedma, mstorsjo Differential Revision: https://reviews.llvm.org/D134787
2022-09-13[DX] DXContainer does not support COMDATChris Bieneman1-1/+15
The DXContainer is pretty primitive, but doesn't support COMDAT. We need to set that in the Triple so that Clang won't try to emit COMDATs.
2022-05-23[SPIR-V] Allow setting SPIR-V version via target triple.Anastasia Stulova1-0/+74
Currently added versions are from v1.0 to v1.5, other versions can be added as needed. This change also adds documentation about SPIR-V target support in LLVM. Differential Revision: https://reviews.llvm.org/D124776
2022-04-20[SPIR-V](3/6) Add MC layer, object file support, and InstPrinterIlia Diachkov1-0/+8
The patch adds SPIRV-specific MC layer implementation, SPIRV object file support and SPIRVInstPrinter. Differential Revision: https://reviews.llvm.org/D116462 Authors: Aleksandr Bezzubikov, Lewis Crawford, Ilia Diachkov, Michal Paszkowski, Andrey Tretyakov, Konrad Trifunovic Co-authored-by: Aleksandr Bezzubikov <zuban32s@gmail.com> Co-authored-by: Ilia Diachkov <iliya.diyachkov@intel.com> Co-authored-by: Michal Paszkowski <michal.paszkowski@outlook.com> Co-authored-by: Andrey Tretyakov <andrey1.tretyakov@intel.com> Co-authored-by: Konrad Trifunovic <konrad.trifunovic@intel.com>
2022-04-05[PS5] Add PS5 as a legal triple componentPaul Robinson1-0/+5
2022-03-29Add DXContainerChris Bieneman1-0/+3
DXIL is wrapped in a container format defined by the DirectX 11 specification. Codebases differ in calling this format either DXBC or DXILContainer. Since eventually we want to add support for DXBC as a target architecture and the format is used by DXBC and DXIL, I've termed it DXContainer here. Most of the changes in this patch are just adding cases to switch statements to address warnings. Reviewed By: pete Differential Revision: https://reviews.llvm.org/D122062
2022-03-29[ADT] Flesh out HLSL raytracing environmentsChris Bieneman1-0/+36
Fleshing this out now allows me to rely on enum math to translate values rather than having to translate the off cases. I should have added this in the first pass, but wasn't thinking about it.
2022-03-19Add DXIL tripleChris Bieneman1-0/+86
This patch adds triple support for: * dxil architecture * shadermodel OS (with version parsing) * shader stages as environment Reviewed By: MaskRay, pete Differential Revision: https://reviews.llvm.org/D122031
2022-02-22Add DriverKit supportEgor Zhdan1-0/+17
This patch is the first in a series of patches to upstream the support for Apple's DriverKit. Once complete, it will allow targeting DriverKit platform with Clang similarly to AppleClang. This code was originally authored by JF Bastien. Differential Revision: https://reviews.llvm.org/D118046
2022-02-10[LoongArch 1/6] Add triples loongarch{32,64} for the upcoming LoongArch targetLu Weining1-0/+46
This is the first patch to incrementally add an MC layer for LoongArch to LLVM. This patch also adds unit testcases for these new triples. RFC for adding this new backend: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154371.html Differential revision: https://reviews.llvm.org/D115857
2022-01-28[clang][ARM] Emit warnings when PACBTI-M is used with unsupported architecturesAmilendra Kodithuwakku1-0/+144
Branch protection in M-class is supported by - Armv8.1-M.Main - Armv8-M.Main - Armv7-M Attempting to enable this for other architectures, either by command-line (e.g -mbranch-protection=bti) or by target attribute in source code (e.g. __attribute__((target("branch-protection=..."))) ) will generate a warning. In both cases function attributes related to branch protection will not be emitted. Regardless of the warning, module level attributes related to branch protection will be emitted when it is enabled via the command-line. The following people also contributed to this patch: - Victor Campos Reviewed By: chill Differential Revision: https://reviews.llvm.org/D115501
2021-12-07Revert "Revert "Use VersionTuple for parsing versions in Triple, fixing ↵James Farrell1-77/+77
issues that caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible."" This reverts commit 63a6348cad6caccf285c1661bc60d8ba5a40c972. Differential Revision: https://reviews.llvm.org/D115254
2021-12-06Revert "Use VersionTuple for parsing versions in Triple, fixing issues that ↵James Farrell1-77/+77
caused the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible." This reverts commit 50324670342d9391f62671685f4d6b4880a4ea9a.
2021-12-06Use VersionTuple for parsing versions in Triple, fixing issues that caused ↵James Farrell1-77/+77
the original change to be reverted. This makes it possible to distinguish between "16" and "16.0" after parsing, which previously was not possible. This reverts commit 40d5eeac6cd89a2360c3ba997cbaa816abca828c. Differential Revision: https://reviews.llvm.org/D114885
2021-11-30Revert "Use VersionTuple for parsing versions in Triple. This makes it ↵Nikita Popov1-77/+77
possible to distinguish between "16" and "16.0" after parsing, which previously was not possible." This reverts commit 1e8286467036d8ef1a972de723f805a4981b2692. llvm/test/Transforms/LoopStrengthReduce/X86/2009-11-10-LSRCrash.ll fails with assertion failure: llc: /home/nikic/llvm-project/llvm/include/llvm/ADT/Optional.h:196: T& llvm::optional_detail::OptionalStorage<T, true>::getValue() & [with T = unsigned int]: Assertion `hasVal' failed. ... #8 0x00005633843af5cb llvm::MCStreamer::emitVersionForTarget(llvm::Triple const&, llvm::VersionTuple const&) #9 0x0000563383b47f14 llvm::AsmPrinter::doInitialization(llvm::Module&)
2021-11-30Use VersionTuple for parsing versions in Triple. This makes it possible to ↵James Farrell1-77/+77
distinguish between "16" and "16.0" after parsing, which previously was not possible. See also https://github.com/android/ndk/issues/1455. Differential Revision: https://reviews.llvm.org/D114163
2021-11-08[SPIR-V] Add SPIR-V triple and clang target info.Anastasia Stulova1-0/+28
Add new triple and target info for ‘spirv32’ and ‘spirv64’ and, thus, enabling clang (LLVM IR) code emission to SPIR-V target. The target for SPIR-V is mostly reused from SPIR by derivation from a common base class since IR output for SPIR-V is mostly the same as SPIR. Some refactoring are made accordingly. Added and updated tests for parts that are different between SPIR and SPIR-V. Patch by linjamaki (Henry Linjamäki)! Differential Revision: https://reviews.llvm.org/D109144
2021-10-21[MIPS] Fix switching between 32/64-bit variants of r6 target triplesYunQiang Su1-0/+68
If clang driver gets 64-bit r6 target triple like `mipsisa64r6` and additional option forces switching to generation of 32-bit code, it loses r6 abi and generates 32-bit r2-r5 abi code. ``` $ clang -target mipsisa64r6-linux-gnu -mabi=32 ``` This patch fixes the problem. - Add optional `SubArchType` argument to the `Triple::setArch()` method. - Implement generation of mips r6 target triples in the `Triple::getArchName()` method. Differential Revision: https://reviews.llvm.org/D110514.diff
2021-04-21Delete le32/le64 targetsFangrui Song1-16/+0
They are unused now. Note: NaCl is still used and is currently expected to be needed until 2022-06 (https://blog.chromium.org/2020/08/changes-to-chrome-app-support-timeline.html). Differential Revision: https://reviews.llvm.org/D100981
2021-04-21[ARM][Driver][Windows] Allow command-line upgrade to Armv8.Simon Tatham1-0/+1
If you gave clang the options `--target=arm-pc-windows-msvc` and `-march=armv8-a+crypto` together, the crypto extension would not be enabled in the compilation, and you'd see the following warning message suggesting that the 'armv8-a' had been ignored: clang: warning: ignoring extension 'crypto' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument] This happens because Triple::getARMCPUForArch(), for the Win32 OS, unconditionally returns "cortex-a9" (an Armv7 CPU) regardless of MArch, which overrides the architecture setting on the command line. I don't think that the combination of Windows and AArch32 _should_ unconditionally outlaw the use of the crypto extension. MSVC itself doesn't think so: you can perfectly well compile Thumb crypto code using its AArch32-targeted compiler. All the other default CPUs in the same switch statement are conditional on a particular MArch setting; this is the only one that returns a particular CPU _regardless_ of MArch. So I've fixed this one by adding a condition, so that if you ask for an architecture *above* v7, the default of Cortex-A9 no longer overrides it. Reviewed By: mstorsjo Differential Revision: https://reviews.llvm.org/D100937
2021-03-25[Triple][Driver] Add muslx32 environment and use /lib/ld-musl-x32.so.1 for ↵Fangrui Song1-0/+6
-dynamic-linker Differential Revision: https://reviews.llvm.org/D99308
2021-02-04[PS4] Allow triple to reflect the new company name.Paul Robinson1-0/+11
2021-01-06Fix failing triple test for macOS 11 with non-zero minor versions.Amara Emerson1-0/+8
Differential Revision: https://reviews.llvm.org/D94197
2021-01-02[PowerPC] Add the LLVM triple for powerpcle [1/5]Brandon Bergren1-1/+1
Add a triple for powerpcle-*-*. This is a little-endian encoding of the 32-bit PowerPC ABI, useful in certain niche situations: 1) A loader such as the FreeBSD loader which will be loading a little endian kernel. This is required for PowerPC64LE to load properly in pseries VMs. Such a loader is implemented as a freestanding ELF32 LSB binary. 2) Userspace emulation of a 32-bit LE architecture such as x86 on 64-bit hosts such as PowerPC64LE with tools like box86 requires having a 32-bit LE toolchain and library set, as they operate by translating only the main binary and switching to native code when making library calls. 3) The Void Linux for PowerPC project is experimenting with running an entire powerpcle userland. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D93918
2020-12-03[Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth.Ahmed Bougacha1-0/+5
This also teaches MachO writers/readers about the MachO cpu subtype, beyond the minimal subtype reader support present at the moment. This also defines a preprocessor macro to allow users to distinguish __arm64__ from __arm64e__. arm64e defaults to an "apple-a12" CPU, which supports v8.3a, allowing pointer-authentication codegen. It also currently defaults to ios14 and macos11. Differential Revision: https://reviews.llvm.org/D87095
2020-09-02[RFC][Target] Add a new triple called Triple::cskyZi Xuan Wu1-0/+29
Before upstream a new target called CSKY, make a new triple of that called Triple::csky. For now, it's a 32-bit little endian target and the detail can be referred at D86269. This is the split part of D86269, which add a new target called CSKY. Differential Revision: https://reviews.llvm.org/D86505
2020-08-11[SystemZ/ZOS] Add binary format goff and operating system zos to the tripleKai Nacke1-0/+24
Adds the binary format goff and the operating system zos to the triple class. goff is selected as default binary format if zos is choosen as operating system. No further functionality is added. Reviewers: efriedma, tahonermann, hubert.reinterpertcast, MaskRay Reviewed By: efriedma, tahonermann, hubert.reinterpertcast Differential Revision: https://reviews.llvm.org/D82081
2020-07-28Re-land "[PowerPC] Remove QPX/A2Q BGQ/BGP CNK support"Jinsong Ji1-35/+0
This reverts commit bf544fa1c3cb80f24d85e84559fb11193846259f. Fixed the typo in PPCInstrInfo.cpp.
2020-07-27Revert "[PowerPC] Remove QPX/A2Q BGQ/BGP CNK support"Jinsong Ji1-0/+35
This reverts commit adffce71538e219aab4eeb024819baa7687262ff. This is breaking test-suite, revert while investigation.
2020-07-27[PowerPC] Remove QPX/A2Q BGQ/BGP CNK supportJinsong Ji1-35/+0
Per RFC http://lists.llvm.org/pipermail/llvm-dev/2020-April/141295.html no one is making use of QPX/A2Q/BGQ/BGP CNK anymore. This patch remove the support of QPX/A2Q in llvm, BGQ/BGP in clang, CNK support in openmp/polly. Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D83915
2020-06-26Revert rGf0bab7875e78e01c149d12302dcc4b6d4c43e25c - "Triple.h - reduce ↵Simon Pilgrim1-1/+0
Twine.h include to forward declarations. NFC." This causes ICEs on the clang-ppc64be buildbots and I've limited ability to triage the problem.
2020-06-26Triple.h - reduce Twine.h include to forward declarations. NFC.Simon Pilgrim1-0/+1
Move include down to a number of other files that had an implicit dependency on the Twine class.
2020-06-22[Triple] support macOS 11 os version numberAlex Lorenz1-0/+60
macOS goes to 11! This commit adds support for the new version number by ensuring that existing version comparison routines, and the 'darwin' OS identifier understands the new numbering scheme. It also adds a new utility method 'getCanonicalVersionForOS', which lets users translate some uses of macOS 10.16 into macOS 11. This utility method will be used in upcoming clang and swift commits. Differential Revision: https://reviews.llvm.org/D82337
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-2/+2
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-09[VE] Target stub for NEC SX-AuroraKazushi (Jam) Marukawa1-0/+8
Summary: This patch registers the 've' target: the NEC SX-Aurora TSUBASA Vector Engine. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D69103
2020-01-08[PowerPC]: Add powerpcspe target triple subarch componentJustin Hibbits1-0/+7
Summary: This allows the use of '-target powerpcspe-unknown-linux-gnu' or 'powerpcspe-unknown-freebsd' to be used, instead of '-target powerpc-unknown-linux-gnu -mspe'. Reviewed By: dim Differential Revision: https://reviews.llvm.org/D72014
2019-08-01Add support for openSUSE RISC-V tripleSam Elliott1-0/+6
Reviewers: asb Reviewed By: asb Subscribers: lenary, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, lebedev.ri, kito-cheng, shiva0217, rogfer01, dexonsmith, rkruppe, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63497 Patch by Andreas Schwab (schwab) llvm-svn: 367565
2019-07-08Standardize on MSVC behavior for triples with no environmentReid Kleckner1-0/+2
Summary: This makes it so that IR files using triples without an environment work out of the box, without normalizing them. Typically, the MSVC behavior is more desirable. For example, it tends to enable things like constant merging, use of associative comdats, etc. Addresses PR42491 Reviewers: compnerd Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64109 llvm-svn: 365387
2019-07-08[Triple] Add isRISCV functionAlex Bradbury1-0/+2
This matches isARM, isThumb, isAArch64 and similar helpers. Future commits which clean-up code that currently checks for Triple::riscv32 || Triple::riscv64. Differential Revision: https://reviews.llvm.org/D54215 Patch by Simon Cook. Test case added by Alex Bradbury. llvm-svn: 365327
2019-07-03[triple] Use 'macabi' environment name for the Mac Catalyst triplesAlex Lorenz1-2/+2
The 'macabi' environment name is preferred instead of 'maccatalyst'. llvm-svn: 364988
2019-07-02[triple] add 'macCatalyst' environment typeAlex Lorenz1-0/+11
Mac Catalyst is a new deployment platform in macOS Catalina. Differential Revision: https://reviews.llvm.org/D64097 llvm-svn: 364971
2019-05-15arm64_32: add some unittests that were in the wrong commit.Tim Northover1-0/+11
Accidentally dropped them when committing the arm64_32 binutils support. There's no change to real code. llvm-svn: 360763
2019-04-30[WebAssembly] Test the "wasm32-wasi" tripleDan Gohman1-8/+18
Add triple tests for "wasm32-wasi" and "wasm64-wasi", and also remove the "-musl" component from the existing wasm triple tests as we're not using that in practice (WASI libc is derived in part from musl, but it is not fully musl-compatible). Differential Revision: https://reviews.llvm.org/D61334 Reviewer: sbc100 llvm-svn: 359629
2019-03-12Add XCOFF triple object format type for AIXJason Liu1-0/+8
This patch adds an XCOFF triple object format type into LLVM. This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform. Differential Revision: https://reviews.llvm.org/D58930 llvm-svn: 355989
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
2019-01-16[WebAssembly] COWS has been renamed to WASI.Dan Gohman1-8/+8
llvm-svn: 351297
2019-01-15[WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses itDan Gohman1-0/+18
This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. [Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/ Differential Revision: https://reviews.llvm.org/D56553 llvm-svn: 351163