| Age | Commit message (Collapse) | Author |
|---|
|
|
|
While I am at it, this patch converts one of the loops to use
llvm::is_contained.
Identified with modernize-loop-convert.
|
|
Per Intel Architecture Instruction Set Extensions Programming Reference
rev. 60 (https://cdrdv2.intel.com/v1/dl/getContent/671368), table 1-2,
NVL supports APX and AVX10.2
|
|
|
|
As in title. AVX10.x doesn't distinguish between available vector
lengths.
-mattr=avx10.x-512 and defining of macros with _512 is kept for compatibility.
Bit-positions of avx10.1/2 features in compiler-rt and X86TargetParser
are synced to match those in the gcc.
|
|
|
|
|
|
Xnack processing is essential and performed at the frontend to enable
ASan instrumentation for AMDGPU device code. Certain AMDGPU subtargets
like gfx1250 && gfx1251 don't have to enable 'xnack+' explictly in
'--offload-arch=' for device ASan instrumentation.
|
|
Update all uses of variadic `.Cases` to use the initializer list
overload instead. I plan to mark variadic `.Cases` as deprecated in a
followup PR.
For more context, see https://github.com/llvm/llvm-project/pull/163117.
|
|
Per Intel Architecture Instruction Set Extensions Programming Reference
rev. 59 (https://cdrdv2.intel.com/v1/dl/getContent/671368), Revision
History entry for revision -59, AMX-TRANSPOSE was removed
|
|
Prior to this change, the data layout calculation would not account for
explicitly set `-mabi=elfv2` on `powerpc64-unknown-linux-gnu`, a target
that defaults to `elfv1`.
This is loosely inspired by the equivalent ARM / RISC-V code.
`make check-llvm` passes fine for me, though AFAICT all the tests
specify the data layout manually so there isn't really a test for this
and I am not really sure what the best way to go about adding one would
be.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Identified with modernize-use-nullptr.
|
|
STAR-MC3 is an Armv8.1m CPU.
Technical specificationa available at:
https://www.armchina.com/download/Documents/TRM?infoId=240
|
|
This introduces the Armv9.7-A architecture version, including the
relevant command-line option for -march.
More details about the Armv9.7-A architecture version can be found at:
* https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2025
* https://developer.arm.com/documentation/109697/2025_09/2025-Architecture-Extensions
* https://developer.arm.com/documentation/ddi0602/2025-09/
Co-authored-by: Caroline Concatto <caroline.concatto@arm.com>
|
|
|
|
supports (#164349)
XSfvfbfexp16e, XSfvfexp16e, and XSfvfexp32e are SiFive's vector
exponential instruction extensions of BFloat16, F16, and F32,
respectively. Spec:
https://www.sifive.com/document-file/exponential-function-instruction-xsfvfexp32e-xsfvf
XSfvfexpa and XSfvfexpa64e are SiFive's vector exponential approximation
instruction extensions where the former supports F16 and F32 and the
latter covers F64. These instructions approximate 2 raised to a
fractional power. Spec:
https://www.sifive.com/document-file/exponential-approximation-instruction-xsfvfexpa-ex
This patch adds their corresponding features and MC supports.
---------
Co-authored-by: Jesse Huang <jesse.huang@sifive.com>
Co-authored-by: Craig Topper <craig.topper@sifive.com>
|
|
This introduces the support for 32-bit ARM Fuchsia target which uses the
aapcs-linux ABI defaulting to thumbv8a as the target.
|
|
Per Intel Architecture Instruction Set Extensions Programming Reference
rev. 59 (https://cdrdv2.intel.com/v1/dl/getContent/671368), table 1-2,
DMR doesn't support USER_MSR (URDMSR and UWRMSR instructions)
|
|
Update `.Cases` and `.CasesLower` with 4+ args to use the
`initializer_list` overload. The deprecation of these functions will
come in a separate PR.
For more context, see: https://github.com/llvm/llvm-project/pull/163405.
|
|
|
|
The OS version is added to the triple with the value returned by uname.
However, PASE uses different versioning from AIX, so the uname value
needs to be mapped to AIX first.
|
|
Add support for Nova Lake, per Intel Architecture Instruction Set
Extensions Programming Reference rev. 59
(https://cdrdv2.intel.com/v1/dl/getContent/671368)
|
|
This explicitly adds two 3-element vectors to the DataLayout so that
they'll be element-aligned. We need to do this more generally for
vectors, but this unblocks some very common cases.
Workaround for #123968
|
|
This patch replaces LLVM_ATTRIBUTE_UNUSED with [[maybe_unused]]. Note
that this patch adjusts the placement of [[maybe_unused]] to comply
with the C++17 language.
|
|
(#163549)
Switch to the `.Cases({S0, S1, ...}, Value)` overload instead, and the
manually-enumerated overloads with 6+ arguments are getting deprecated
in https://github.com/llvm/llvm-project/pull/163405.
This pre-commits API updates ahead of the deprecation to make potential
reverts cleaner. This was already reviewed in #163405.
|
|
Add support for Wildcat Lake, per Intel Architecture Instruction Set
Extensions Programming Reference rev. 59
(https://cdrdv2.intel.com/v1/dl/getContent/671368)
|
|
Per Intel Architecture Instruction Set Extensions Programming Reference
rev. 59 (https://cdrdv2.intel.com/v1/dl/getContent/671368), table 1-2,
PTL doesn't have support for PREFETCHI.
|
|
This patch supports the naive vset* insertion. If the state(tm, tn, tk,
sew, widen) changes, it emits all of the vset* instructions that are
needed, partial compatibility is not supported yet.
This is follow up patch for:
https://github.com/llvm/llvm-project/pull/133031
Co-authored-by: Piyou Chen <piyou.chen@sifive.com>
Co-authored-by: Craig Topper <craig.topper@sifive.com>
|
|
Closes #95219
|
|
Add toolchain support for the
[WALI](https://doc.rust-lang.org/rustc/platform-support/wasm32-wali-linux.html)
target as per its corresponding
[RFC](https://discourse.llvm.org/t/rfc-new-wasm-linux-target-support/88203)
|
|
|
|
This replaces the original arch check.
|
|
Summary:
This patch has broken the `libc` build bot. I could work around that but
the changes seem unnecessary.
This reverts commit 9ba844eb3a21d461c3adc7add7691a076c6992fc.
|
|
When handling CUDA ELF files via objdump or LLDB, the ELF parser in LLVM
needs to distinguish if an ELF file is sass or not, which requires a
triple for sass to exist in llvm. This patch includes all the necessary
changes for LLDB and objdump to correctly identify these files with the
correct triple.
|
|
Just directly check x86_64. isArch64Bit just adds extra
steps around this.
|
|
This patch adds MC support for Zvfofp8min
https://github.com/aswaterman/riscv-misc/blob/main/isa/zvfofp8min.adoc.
|
|
|
|
- cpuid bit for prefetchi is different from Intel
(https://docs.amd.com/v/u/en-US/24594_3.37)
- Fix cpu family model numbers
|
|
|
|
Clang and other frontends generally need the LLVM data layout string in
order to generate LLVM IR modules for LLVM. MLIR clients often need it
as well, since MLIR users often lower to LLVM IR.
Before this change, the LLVM datalayout string was computed in the
LLVM${TGT}CodeGen library in the relevant TargetMachine subclass.
However, none of the logic for computing the data layout string requires
any details of code generation. Clients who want to avoid duplicating
this information were forced to link in LLVMCodeGen and all registered
targets, leading to bloated binaries. This happened in PR #145899,
which measurably increased binary size for some of our users.
By moving this information to the TargetParser library, we
can delete the duplicate datalayout strings in Clang, and retain the
ability to generate IR for unregistered targets.
This is intended to be a very mechanical LLVM-only change, but there is
an immediately obvious follow-up to clang, which will be prepared
separately.
The vast majority of data layouts are computable with two inputs: the
triple and the "ABI name". There is only one exception, NVPTX, which has
a cl::opt to enable short device pointers. I invented a "shortptr" ABI
name to pass this option through the target independent interface.
Everything else fits. Mips is a bit awkward because it uses a special
MipsABIInfo abstraction, which includes members with codegen-like
concepts like ABI physical registers that can't live in TargetParser. I
think the string logic of looking for "n32" "n64" etc is reasonable to
duplicate. We have plenty of other minor duplication to preserve
layering.
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
Co-authored-by: Sergei Barannikov <barannikov88@gmail.com>
|
|
Add "target-feature +i" for RV32I/RV64I.
Current behavior:
RV32E/RV64E: "target-feature +e" "target-feature -i"
RV32I/RV64I: "target-feature -e"
Adding "target-feature +i" explicitly makes the behavior consistent.
|
|
This pr implements support for a root signature as a target, as specified
[here](https://github.com/llvm/wg-hlsl/blob/main/proposals/0029-root-signature-driver-options.md#target-root-signature-version).
This is implemented in the following steps:
1. Add `rootsignature` as a shader model environment type and define
`rootsig` as a `target_profile`. Only valid as versions 1.0 and 1.1
2. Updates `HLSLFrontendAction` to invoke a special handling of
constructing the `ASTContext` if we are considering an `hlsl` file and
with a `rootsignature` target
3. Defines the special handling to minimally instantiate the `Parser`
and `Sema` to insert the `RootSignatureDecl`
4. Updates `CGHLSLRuntime` to emit the constructed root signature decl
as part of `dx.rootsignatures` with a `null` entry function
5. Updates `DXILRootSignature` to handle emitting a root signature
without an entry function
6. Updates `ToolChains/HLSL` to invoke `only-section=RTS0` to strip any
other generated information
Resolves: https://github.com/llvm/llvm-project/issues/150286.
##### Implementation Considerations
Ideally we could invoke this as part of `clang-dxc` without the need of
a source file. However, the initialization of the `Parser` and `Lexer`
becomes quite complicated to handle this.
Technically, we could avoid generating any of the extra information that
is removed in step 6. However, it seems better to re-use the logic in
`llvm-objcopy` without any need for additional custom logic in
`DXILRootSignature`.
|
|
fixes #156068
- We needed to add a new sub arch to the target tripple so we can test
that emulation does not happen when targeting SM6.9
- The HLSL toolchain needed to be updated to handle the conversion of
strings to enums for the new sub arch.
- The emulation is done in DXILIntrinsicExpansion.cpp and needs to be
able to convert both llvm.is.fpclass and lvm.dx.isinf to the proper
emulation
- test updates in TargetParser/TripleTest.cpp, isinf.ll, is_fpclass.ll,
and DXCModeTest.cpp
|
|
The 256-bit maximum vector register size control was removed from AVX10
whitepaper, ref: https://cdrdv2.intel.com/v1/dl/getContent/784343
We have warned these options in LLVM21 through #132542. This patch
removes underlying implementations in LLVM22.
|
|
For context, CheriotRTOS is a custom RTOS co-designed for the CHERIoT
CHERI-enabled RISCV32E platform. It uses a custom ABI and linkage model,
necesitating representing it in the target triple.
|
|
This patch adds MC support for Zvfbfa
https://github.com/aswaterman/riscv-misc/blob/main/isa/zvfbfa.adoc
Since Zvfbfa implies Zve32f, vector floating-point instructions can be
used directly with Zvfbfa extension.
|
|
Factoring in flang, just have a single fillAMDGPUFeatureMap
function doing it all as an external interface and returing
an error.
|
|
If a wavefrontsize32 or wavefrontsize64 is the only possible value
insert it into feature list by default and use that value as an
indication that another wavefront size is not legal.
|
|
A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
https://gitlab.kitware.com/cmake/cmake/-/commit/ff03db6657c38c8cf992877ea66174c33d0bcb0b
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
|
|
Due to it results in more losses than gains.
|
