| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
Differential Revision: https://reviews.llvm.org/D138017
|
|
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
|
|
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
|
|
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
|
|
Followup D125412, return the correct arch name for Arm64EC
Reviewed By: efriedma, mstorsjo
Differential Revision: https://reviews.llvm.org/D134787
|
|
`llvm` and downstream internal callers no longer use `array_lengthof`, so drop
the include everywhere.
Differential Revision: https://reviews.llvm.org/D133600
|
|
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
|
|
Part of patchset to add initial support for ARM64EC.
Per discussion on review, using the triple arm64ec-pc-windows-msvc. The
parsing works the same way as Apple's alternate Arm ABI "arm64e".
Differential Revision: https://reviews.llvm.org/D125412
|
|
With C++17 there is no Clang pedantic warning or MSVC C5051.
|
|
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
|
|
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>
|
|
Add support for i386, s390x in Triple::getArchTypeForLLVMName.
Differential Revision: https://reviews.llvm.org/D122003
|
|
|
|
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
|
|
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.
|
|
Bringing in HLSL as a language as well as language options for each of
the HLSL language standards.
While the HLSL language is unimplemented, this patch adds the
HLSL-specific preprocessor defines which enables testing of the command
line options through the driver.
Reviewed By: pete, rnk
Differential Revision: https://reviews.llvm.org/D122087
|
|
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
|
|
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
|
|
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
|
|
This moves the dependency of several files on include/llvm/ADT/STLExtras.h to
the much shorter llvm/ADT/STLArrayExtras.h
Differential Revision: https://reviews.llvm.org/D118342
|
|
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
|
|
As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).
|
|
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
|
|
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
|
|
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
|
|
|
|
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
|
|
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.
|
|
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
|
|
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&)
|
|
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
|
|
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
|
|
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
|
|
armv9-a, armv9.1-a and armv9.2-a can be targeted using the -march option
both in ARM and AArch64.
- Armv9-A maps to Armv8.5-A.
- Armv9.1-A maps to Armv8.6-A.
- Armv9.2-A maps to Armv8.7-A.
- The SVE2 extension is enabled by default on these architectures.
- The cryptographic extensions are disabled by default on these
architectures.
The Armv9-A architecture is described in the Arm® Architecture Reference
Manual Supplement Armv9, for Armv9-A architecture profile
(https://developer.arm.com/documentation/ddi0608/latest).
Reviewed By: SjoerdMeijer
Differential Revision: https://reviews.llvm.org/D109517
|
|
|
|
This partially reverts commit 77ac823fd285973cfb3517932c09d82e6a32f46d.
Halide uses le32/le64 (https://github.com/halide/Halide/pull/5934).
Temporarily brings back the code part to give them some time for migration.
|
|
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
|
|
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
|
|
-dynamic-linker
Differential Revision: https://reviews.llvm.org/D99308
|
|
- Infrastructure for the target (i.e. build files, target triple etc.)
- All of the target description TableGen file
Authors: myhsu, m4yers, glaubitz
Differential Revision: https://reviews.llvm.org/D88389
|
|
This matches the platform default for GCC. It primarily matters when the
integrated assembler is not used as there is no default CPU defined for
ARMv7-A and GNU as is upset with -mcpu=generic.
|
|
|
|
|
|
Add the aarch64[_be]-*-gnu_ilp32 targets to support the GNU ILP32 ABI for AArch64.
The needed codegen changes were mostly already implemented in D61259, which added support for the watchOS ILP32 ABI. The main changes are:
- Wiring up the new target to enable ILP32 codegen and MC.
- ILP32 va_list support.
- ILP32 TLSDESC relocation support.
There was existing MC support for ELF ILP32 relocations from D25159 which could be enabled by passing "-target-abi ilp32" to llvm-mc. This was changed to check for "gnu_ilp32" in the target triple instead. This shouldn't cause any issues since the existing support was slightly broken: it was generating ELF64 objects instead of the ELF32 object files expected by the GNU ILP32 toolchain.
This target has been tested by running the full rustc testsuite on a big-endian ILP32 system based on the GCC ILP32 toolchain.
Reviewed By: kristof.beyls
Differential Revision: https://reviews.llvm.org/D94143
|
|
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
|
|
This extends the command-line support for the 'armv8.7-a' architecture
name to the ARM target.
Based on a patch written by Momchil Velikov.
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D93231
|
|
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
|
|
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
|
|
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
|
