These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
FMV priority is the returned value of a polymorphic function. On RISC-V
and X86 targets a 32-bit value is enough. On AArch64 we currently need
64 bits and we will soon exceed that. APInt seems to be a suitable
replacement for uint64_t, presumably with minimal compile time overhead.
It allows bit manipulation, comparison and variable bit width.
Add support for big-endian RISC-V ELF files:
- Add riscv32be/riscv64be target architectures to Triple
- Support elf32-bigriscv and elf64-bigriscv output targets in
llvm-objcopy
- Update ELFObjectFile to handle BE RISC-V format strings and
architecture detection
- Add BE RISC-V support to RelocationResolver
- Add tests for new functionality
This is a subset of a bigger RISC-V big-endian support patch, containing
only the llvm-objcopy and libObject changes. Other changes will be added
later.
PR #145685 introduced constructor overload ambiguity in the Triple
class, causing `updateTripleOSVersion()` to construct Triple objects
with `unknown` instead of the configured target triple (e.g.,
`powerpc-ibm-aix7.3.0.0`). This results in Clang driver errors like
`error: unknown target triple 'unknown'`.
Used `Twine` constructor with braced initialization to bypass ambiguity.
---------
Co-authored-by: Tony Varghese <tony.varghese@ibm.com>
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
I encountered the assertion failure `Assertion
TmpAsmInfo->getExceptionHandlingType() ==
getTargetTriple().getDefaultExceptionHandling() && "MCAsmInfo and Triple
disagree on default exception handling type"' failed`.
Currently the default exception handling type is scattered
across the backends in MCAsmInfo constructors. Allow this
to be computed from the triple so the IR can centrally determine
the set of ABI calls.
Manually submitting, closes#147225
This patch adds support for -mcpu=gb10 (NVIDIA GB10). This is a
big.LITTLE cluster of Cortex-X925 and Cortex-A725 cores. The appropriate
MIDR numbers are added to detect them in -mcpu=native.
We did not add an -mcpu=cortex-x925.cortex-a725 option because GB10 does
include the crypto instructions which we want on by default, and the
current convention is to not enable such extensions for Arm Cortex cores
in -mcpu where they are optional in the IP.
Relevant GCC patch:
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687005.html
Adds sve-sha3 to reference FEAT_SVE_SHA3 without specifically enabling
SVE2. The SVE2 requirement for AES, SHA3 and Bitperm is replaced with
SVE for non-streaming function.
Consolidate ABI parsing logic in TargetParser where
computeDefaultTargetABI is defined, instead of splitting it into the
backend. We need the full ABI information computable in
RuntimeLibcallsInfo
1. The PR proceeds with a backend target hook to allow front-ends to
determine what target features are available in a compilation based on
the CPU name.
2. Fix a backend target feature bug that supports HTM for
Power8/9/10/11. However, HTM is only supported on Power8/9 according to
the ISA.
3. All target features that are hardcoded in PPC.cpp can be retrieved
from the backend target feature. I have double-checked that the
hardcoded logic for inferring target features from the CPU in the
frontend(PPC.cpp) is the same as in PPC.td.
The reland patch addressed the comment
https://github.com/llvm/llvm-project/pull/137670#discussion_r2143541120
The `targetFeatureToExtension` function used by
reconstructFromParsedFeatures only found positive `+FEATURE` strings,
but not negative `-FEATURE` strings. Extend the function to handle both
to fix `reconstructFromParsedFeatures`.
This reverts commit 9208b343e962b9f1140ee345c0050a3920bdcbf2.
TargetParser shouldn't re-run the PPC subtarget tablegen target, it
should define its own `-gen-ppc-target-def` rule like all the other
targets do in llvm/include/llvm/TargetParser/CMakeLists.txt .
One user reported that there are incorrect CMake dependencies after this
change, so I will roll this back in the meantime.
1. The PR proceeds with a backend target hook to allow front-ends to
determine what target features are available in a compilation based on
the CPU name.
2. Fix a backend target feature bug that supports HTM for
Power8/9/10/11. However, HTM is only supported on Power8/9 according to
the ISA.
3. All target features that are hardcoded in PPC.cpp can be retrieved
from the backend target feature. I have double-checked that the
hardcoded logic for inferring target features from the CPU in the
frontend(PPC.cpp) is the same as in PPC.td.
We can get the `mvendorid/marchid/mimpid` via hwprobe and then we
can compare these IDs with those defined in processors to find the
CPU name.
With this change, `-mcpu/-mtune=native` can set the proper name.
AAPCS64 reserves any of X9-X15 for a compiler to choose to use for this
purpose, and says not to use X16 or X18 like GCC (and the previous
implementation) chose to use. The X18 register may need to get used by
the kernel in some circumstances, as specified by the platform ABI, so
it is generally an unwise choice. Simply choosing a different register
fixes the problem of this being broken on any platform that actually
follows the platform ABI (which is all of them except EABI, if I am
reading this linux kernel bug correctly
https://lkml2.uits.iu.edu/hypermail/linux/kernel/2001.2/01502.html). As
a side benefit, also generate slightly better code and avoids needing
the compiler-rt to be present. I did that by following the XCore
implementation instead of PPC (although in hindsight, following the
RISCV might have been slightly more readable). That X18 is wrong to use
for this purpose has been known for many years (e.g.
https://www.mail-archive.com/gcc@gcc.gnu.org/msg76934.html) and also
known that fixing this to use one of the correct registers is not an ABI
break, since this only appears inside of a translation unit. Some of the
other temporary registers (e.g. X9) are already reserved inside llvm for
internal use as a generic temporary register in the prologue before
saving registers, while X15 was already used in rare cases as a scratch
register in the prologue as well, so I felt that seemed the most logical
choice to choose here.
* Translate the following versions to 26.
* watchOS 12 -> 26
* visionOS 3 -> 26
* macos 16 -> 26
* iOS 19 -> 26
* tvOS 19 -> 26
* Emit diagnostics, but allow conversion when clients attempt to use
invalid gaps in OS versioning in availability.
* For target-triples, only allow "valid" versions for implicit
conversions.
This adds support under LoongArch for the target("..") attributes.
The supported formats are:
- "arch=<arch>" strings, that specify the architecture features for a
function as per the -march=arch option.
- "tune=<cpu>" strings, that specify the tune-cpu cpu for a function as
per -mtune.
- "<feature>", "no-<feature>" enabled/disables the specific feature.
This adds assembler/disassembler support for XSfmmbase 0.6 and related
SiFive matrix multiplication extensions based on the spec here
https://www.sifive.com/document-file/xsfmm-matrix-extensions-specification
Functionality-wise, this is the same as the Zvma extension proposal that
SiFive shared with the Attached Matrix Extension Task Group. The
extension names and instruction mnemonics have been changed to use
vendor prefixes.
Note this is a non-conforming extension as the opcodes used here are in
the standard opcode space in OP-V or OP-VE.
---------
Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
This patch adds initial support for the recently announced Armv9
Cortex-A320 processor.
For more information, including the Technical Reference Manual, see:
https://developer.arm.com/Processors/Cortex-A320
---------
Co-authored-by: Oliver Stannard <oliver.stannard@arm.com>
The `llvm-headers` target wasn't depending on the generated TargetParser
headers, so they'd be flakily installed or not installed depending on
which order the build steps ran in. Add an explicit dependency to fix
this, and switch to a single `target_parser_gen` target to mirror the
pattern used by `intrinsics_gen` (which also fixes a few other missing
dependencies). Switch `llvm-headers` to use `add_dependencies` instead
of `DEPENDS` for the tablegen dependencies as well, since `DEPENDS` is
only intended for creating a file-level dependency on the output of an
`add_custom_command` in the same CMakeLists.txt (see `DEPENDS` under
https://cmake.org/cmake/help/latest/command/add_custom_target.html).
