| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add MC layer support for Andes XAndesVSIntH extension. The spec is
available at:
https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release
|
|
|
|
This patch adds MC support for Zvfofp8min
https://github.com/aswaterman/riscv-misc/blob/main/isa/zvfofp8min.adoc.
|
|
This adds the MC support of Zibi v0.1 experimental extension.
References:
*
https://lf-riscv.atlassian.net/wiki/spaces/USXX/pages/599261201/Branch+with+Immediate+Zibi+Ratification+Plan
* https://lf-riscv.atlassian.net/browse/RVS-3828
* https://github.com/riscv/zibi/releases/tag/v0.1.0
|
|
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
|
|
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.
|
|
for MIPS RV64 P8700. (#155747)
Please refer the
https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf
for more information .
and files like RISCVInstrInfoXMips.td clang formatted .
No Regression found.
---------
Co-authored-by: Craig Topper <craig.topper@sifive.com>
|
|
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.
|
|
This patch implements pages 15-17 from
jhauser.us/RISCV/ext-P/RVP-instrEncodings-015.pdf
Documentation:
jhauser.us/RISCV/ext-P/RVP-baseInstrs-014.pdf
jhauser.us/RISCV/ext-P/RVP-instrEncodings-015.pdf
|
|
The full spec can be found at spacemit-x60 processor support scope:
Section 2.1.2.2 (Features):
https://developer.spacemit.com/documentation?token=BWbGwbx7liGW21kq9lucSA6Vnpb#2.1
This patch only supports assembler.
|
|
These extensions were ratified in November 2024.
|
|
Uses the `CP 4000` registry keys under
`HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\*` to get the
Implementer and Part, which is then provided to a modified form of
`getHostCPUNameForARM` to map to a CPU.
On my local Surface Pro 11 `llc --version` reports:
```
> .\build\bin\llc.exe --version
LLVM (http://llvm.org/):
LLVM version 22.0.0git
Optimized build with assertions.
Default target: aarch64-pc-windows-msvc
Host CPU: oryon-1
```
|
|
Ref:
https://ai.meta.com/blog/next-generation-meta-training-inference-accelerator-AI-MTIA/
This PR contains
1. MTIA: Meta Training and Inference Accelerator as Environment.
2. Meta as the vendor.
### Testing
Added a unittest for the relevant changes
### Reviewers
@clayborg , @jeffreytan81 , @Jlalond
|
|
Remove the Native Client support now that it has finally reached end of life.
|
|
The spec can be found at:
https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release.
The extension includes only two instructions: one for converting from
f32 to f16, and another for converting from f16 to f32.
This patch only implements MC support for XAndesBFHCvt.
|
|
Fixes asserting with windows-elf triples. Should fix regression
reported in https://github.com/llvm/llvm-project/pull/147225#issuecomment-3054190938
I'm not sure this is a valid triple, but I'm guessing the MCJIT usage
is an accident. This does change the behavior from trying to use WinEH
to DwarfCFI; however the backend crashes with WinEH so I'm assuming following
ELF is the more correct option.
|
|
Adds sve-sm4 to reference FEAT_SVE_SM4 without specifically enabling
SVE2.
|
|
getDefaultExceptionHandling. (#147492)
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
|
|
The spec can be found at:
https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release.
This patch only implements MC support for XAndesVSIntLoad.
---------
Co-authored-by: Lino Hsing-Yu Peng <linopeng@andestech.com>
|
|
the extension enabled with xmipscbop.
Please refer "MIPS RV64 P8700/P8700-F Multiprocessing System
Programmer’s Guide" for more info on the extension at
https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf
|
|
instructions. (#145696)
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.
|
|
This fixes a TODO and avoids a special case. Also required
hacking up a few cases to avoid asserting in codegen; it's not
confidence inspiring that there is only one codegen test using
a bridgeos triple and its specifically for the exp10 libcall
names.
This also changes the behavior, losing an extra leading _ in the
emitted name matching the other apple outputs. I have no idea if
this is right or not. IMO it's someone from apple's problem to fix
it and add appropriate test coverage, or we can rip all references
to BridgeOS out from upstream.
|
|
(#144320)
The spec can be found at:
https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release.
This patch only supports assembler. The instructions are similar to
`Zvfbfmin` and the only difference with `Zvfbfmin` is that
`XAndesVBFHCvt` doesn't have mask variant.
|
|
All the changes for v0.2 and v0.3 are either already implemented, or
irrelevant to the compiler implementation.
|
|
|
|
features (#142236)
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`.
|
|
* 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 is for `shlcofideleg` extension, that supports delegating LCOFI
interrupts to VS-mode.
Spec:
https://github.com/riscv/riscv-isa-manual/blob/main/src/hypervisor.adoc
|
|
|
|
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>
|
|
Closes #130217.
https://github.com/riscv/riscv-isa-manual/blob/main/src/q-st-ext.adoc
|
|
The spec can be found at:
https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release.
This patch only supports assembler.
Intrinsics support will be added in a later patch.
|
|
This updates all the extensions to their version in the v0.11.0 spec.
All changes from this version are already implemented or are not
relevant to LLVM.
This change also alphabetises the lists of Xqci extensions, to make
future checks easier, and removes irrelevant info from the usage docs.
|
|
The spec can be found at:
https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release.
This patch only supports assembler.
Intrinsics support will be added in a later patch.
|
|
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>
|
|
This PR aims to add a target for
[managarm](https://github.com/managarm/managarm). The targets
`{x86_64,aarch64,riscv64}-pc-managarm-{kernel,mlibc}` will be supported.
Discourse RFC:
[discourse.llvm.org/t/rfc-new-proposed-managarm-support-for-llvm-and-clang-87845/85884](https://discourse.llvm.org/t/rfc-new-proposed-managarm-support-for-llvm-and-clang-87845/85884)
|
|
The spec can be found at:
https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release.
This patch only supports assembler.
Relocation and fixup for the branch and gp-implied instructions will be
added in a later patch.
|
|
This matches GCC and we supported it in LLVM 17/18.
Fixes #136803
|
|
This Change adds support for two SiFive vendor attributes in clang:
- "SiFive-CLIC-preemptible"
- "SiFive-CLIC-stack-swap"
These can be given together, and can be combined with "machine", but
cannot be combined with any other interrupt attribute values.
These are handled primarily in RISCVFrameLowering:
- "SiFive-CLIC-stack-swap" entails swapping `sp` with `sf.mscratchcsw`
at function entry and exit, which holds the trap stack pointer.
- "SiFive-CLIC-preemptible" entails saving `mcause` and `mepc` before
re-enabling interrupts using `mstatus`. To save these, `s0` and `s1`
are first spilled to the stack, and then the values are read into
these registers. If these registers are used in the function, their
values will be spilled a second time onto the stack with the generic
callee-saved-register handling. At the end of the function interrupts
are disabled again before `mepc` and `mcause` are restored.
This Change also adds support for the following two experimental
extensions, which only contain CSRs:
- XSfsclic - for SiFive's CLIC Supervisor-Mode CSRs
- XSfmclic - for SiFive's CLIC Machine-Mode CSRs
The latter is needed for interrupt support.
The CFI information for this implementation is not correct, but I'd
prefer to correct this in a follow-up. While it's unlikely anyone wants
to unwind through a handler, the CFI information is also used by
debuggers so it would be good to get it right.
Co-authored-by: Ana Pazos <apazos@quicinc.com>
|
|
Support for Ziccamoc is added in this pr.
Specification link:
https://drive.google.com/file/d/12QKRm92cLcEk8-5J9NI91m0fAQOxqNAq/view
---------
Co-authored-by: Tie <Tie@llvm.com>
|
|
MSYS2 uses i686-pc-msys and x86_64-pc-msys as target, and is a fork of
Cygwin. There's an effort underway to try to switch as much as possible
to use -pc-cygwin targets, but the -msys target will be hanging around
for the forseeable future.
|
|
spec: https://github.com/riscvarchive/riscv-smcntrpmf
|
|
Fixes #136564.
|
|
The right name was used in riscv-toolchain-conventions docs.
|
|
`+simd` and `+nosimd` are used to enable or disable NEON Instructions
when compiling for ARM Targets. However, up until now, using these
has not been possible. To enable this, these options are mapped to the
relevant LLVM backend option (`+neon` and `-neon`) so it can be both
enabled and disabled successfully by the user.
Tests have been added to ensure this behaviour is maintained in the
future, along with updates to existing tests as behaviour has now changed
relating to the use of `+simd` and `+nosimd`.
As `simd` has been mapped within the ARMTargetParser.def, support for
this extension is also added for the `--print-support-extensions` command
when the target is AArch32. This will print the `simd` option, along with the
description that relates to the Neon feature. This previously was not
possible as `simd` did not have a related Feature or Negative Feature.
To make this functional as intended, MVE and MVE.FP now rely on their
own Enum identifier, rather than `AEK_SIMD`. While SIMD does refer to
both Neon and Helium technologies, in terms of command line options,
SIMD relates to Neon. Helium relates to MVE and MVE.FP. The Enum
now reflects this too.
|
