mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-25 11:56:08 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/llvm/docs/RISCVUsage.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

434 lines
27 KiB
ReStructuredText
Raw Normal View History

[docs] Add a RISC-V Usage page This follows the pattern set by e.g. SPIR-V, AMDGPU, and WebAssembly. For the moment, this page is fairly minimal stub. I mostly want a place to record which extensions we support, and when that support is not complete, a central place to note that. I'm deliberately starting with a subset of extensions which are pretty straight forward with only one case needing a detail note. I figure the partial support cases are going to need a bunch of discussion, and having each of them in their own review seemed worthwhile. Similarly, the experimental extensions probably fall into the same bucket of triggering a bunch of review discussion. Differential Revision: https://reviews.llvm.org/D133063
2022-09-06 12:06:53 -07:00
=============================
User Guide for RISC-V Target
=============================
.. contents::
:local:
Introduction
============
The RISC-V target provides code generation for processors implementing
supported variations of the RISC-V specification. It lives in the
``llvm/lib/Target/RISCV`` directory.
[RISCV][docs] Document which revision of the specification we implement This is intended to document the decision made in recent discussion, and ratified at the last risc-v sync up call two weeks ago. The wording here turned out to be a bit tricky. I ended up using the word "revision" as the specification internally defines several versioning schemes, and RVI assigns particular meaning to the words "specification version" that I really didn't want to get into. If anyone has suggestions on how to improve this, please don't hesitate to chime in. Differential Revision: https://reviews.llvm.org/D147183
2023-04-03 13:53:22 -07:00
Specification Documents
=======================
There have been a number of revisions to the RISC-V specifications. LLVM aims
to implement the most recent ratified version of the standard RISC-V base ISAs
and ISA extensions with pragmatic variances. The most recent specification can
be found at: https://github.com/riscv/riscv-isa-manual/releases/.
`The official RISC-V International specification page
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
<https://riscv.org/technical/specifications/>`__. is also worth checking, but
[RISCV][docs] Document which revision of the specification we implement This is intended to document the decision made in recent discussion, and ratified at the last risc-v sync up call two weeks ago. The wording here turned out to be a bit tricky. I ended up using the word "revision" as the specification internally defines several versioning schemes, and RVI assigns particular meaning to the words "specification version" that I really didn't want to get into. If anyone has suggestions on how to improve this, please don't hesitate to chime in. Differential Revision: https://reviews.llvm.org/D147183
2023-04-03 13:53:22 -07:00
tends to significantly lag the specifications linked above. Make sure to check
the `wiki for not yet integrated extensions
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
<https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions>`__ and note
[RISCV][docs] Document which revision of the specification we implement This is intended to document the decision made in recent discussion, and ratified at the last risc-v sync up call two weeks ago. The wording here turned out to be a bit tricky. I ended up using the word "revision" as the specification internally defines several versioning schemes, and RVI assigns particular meaning to the words "specification version" that I really didn't want to get into. If anyone has suggestions on how to improve this, please don't hesitate to chime in. Differential Revision: https://reviews.llvm.org/D147183
2023-04-03 13:53:22 -07:00
that in addition, we sometimes carry support for extensions that have not yet
been ratified (these will be marked as experimental - see below) and support
various vendor-specific extensions (see below).
The current known variances from the specification are:
* Unconditionally allowing instructions from zifencei, zicsr, zicntr, and
zihpm without gating them on the extensions being enabled. Previous
revisions of the specification included these instructions in the base
ISA, and we preserve this behavior to avoid breaking existing code. If
a future revision of the specification reuses these opcodes for other
extensions, we may need to reevaluate this choice, and thus recommend
users migrate build systems so as not to rely on this.
* Allowing CSRs to be named without gating on specific extensions. This
applies to all CSR names, not just those in zicsr, zicntr, and zihpm.
[RISCV] Relax rules for ordering s/z/x prefixed extensions in ISA naming strings This was discussed somewhat in D148315. As it stands, we require in RISCVISAInfo::parseArchString (used for e.g. -march parsing in Clang) that extensions are given in the order of z, then s, then x prefixed extensions (after the standard single-letter extensions). However, we recently (in D148315) moved to that order from z/x/s as the canonical ordering was changed in the spec. In addition, recent GCC seems to require z* extensions before s*. My recollection of the history here is that we thought keeping -march as close to the rules for ISA naming strings as possible would simplify things, as there's an existing spec to point to. My feeling is that now we've had incompatible changes, and an incompatibility with GCC there's no real benefit to sticking to this restriction, and it risks making it much more painful than it needs to be to copy a -march= string between GCC and Clang. This patch removes all ordering restrictions so you can freely mix x/s/z extensions. To be very explicit, this doesn't change our behaviour when emitting a canonically ordered extension string (e.g. in build attributes). We of course sort according to the canonical order (as we understand it) in that case. Differential Revision: https://reviews.llvm.org/D149246
2023-06-27 13:28:28 +01:00
* The ordering of ``z*``, ``s*``, and ``x*`` prefixed extension names is not
enforced in user-specified ISA naming strings (e.g. ``-march``).
[RISCV][docs] Document which revision of the specification we implement This is intended to document the decision made in recent discussion, and ratified at the last risc-v sync up call two weeks ago. The wording here turned out to be a bit tricky. I ended up using the word "revision" as the specification internally defines several versioning schemes, and RVI assigns particular meaning to the words "specification version" that I really didn't want to get into. If anyone has suggestions on how to improve this, please don't hesitate to chime in. Differential Revision: https://reviews.llvm.org/D147183
2023-04-03 13:53:22 -07:00
We are actively deciding not to support multiple specification revisions
at this time. We acknowledge a likely future need, but actively defer the
decisions making around handling this until we have a concrete example of
real hardware having shipped and an incompatible change to the
specification made afterwards.
[docs] Add a RISC-V Usage page This follows the pattern set by e.g. SPIR-V, AMDGPU, and WebAssembly. For the moment, this page is fairly minimal stub. I mostly want a place to record which extensions we support, and when that support is not complete, a central place to note that. I'm deliberately starting with a subset of extensions which are pretty straight forward with only one case needing a detail note. I figure the partial support cases are going to need a bunch of discussion, and having each of them in their own review seemed worthwhile. Similarly, the experimental extensions probably fall into the same bucket of triggering a bunch of review discussion. Differential Revision: https://reviews.llvm.org/D133063
2022-09-06 12:06:53 -07:00
Base ISAs
=========
[RISCV][MC] Add support for RV64E Implement MC support for the recently ratified RV64E base instruction set. Differential Revision: https://reviews.llvm.org/D143570
2023-03-23 12:17:57 +00:00
The specification defines five base instruction sets: RV32I, RV32E, RV64I,
RV64E, and RV128I. Currently, LLVM fully supports RV32I, and RV64I. RV32E and
RV64E are supported by the assembly-based tools only. RV128I is not supported.
[docs] Add a RISC-V Usage page This follows the pattern set by e.g. SPIR-V, AMDGPU, and WebAssembly. For the moment, this page is fairly minimal stub. I mostly want a place to record which extensions we support, and when that support is not complete, a central place to note that. I'm deliberately starting with a subset of extensions which are pretty straight forward with only one case needing a detail note. I figure the partial support cases are going to need a bunch of discussion, and having each of them in their own review seemed worthwhile. Similarly, the experimental extensions probably fall into the same bucket of triggering a bunch of review discussion. Differential Revision: https://reviews.llvm.org/D133063
2022-09-06 12:06:53 -07:00
To specify the target triple:
.. table:: RISC-V Architectures
============ ==============================================================
Architecture Description
============ ==============================================================
``riscv32`` RISC-V with XLEN=32 (i.e. RV32I or RV32E)
[RISCV][MC] Add support for RV64E Implement MC support for the recently ratified RV64E base instruction set. Differential Revision: https://reviews.llvm.org/D143570
2023-03-23 12:17:57 +00:00
``riscv64`` RISC-V with XLEN=64 (i.e. RV64I or RV64E)
[docs] Add a RISC-V Usage page This follows the pattern set by e.g. SPIR-V, AMDGPU, and WebAssembly. For the moment, this page is fairly minimal stub. I mostly want a place to record which extensions we support, and when that support is not complete, a central place to note that. I'm deliberately starting with a subset of extensions which are pretty straight forward with only one case needing a detail note. I figure the partial support cases are going to need a bunch of discussion, and having each of them in their own review seemed worthwhile. Similarly, the experimental extensions probably fall into the same bucket of triggering a bunch of review discussion. Differential Revision: https://reviews.llvm.org/D133063
2022-09-06 12:06:53 -07:00
============ ==============================================================
To select an E variant ISA (e.g. RV32E instead of RV32I), use the base
architecture string (e.g. ``riscv32``) with the extension ``e``.
[RISCV][doc] Document profiles in RISCVUsage (#98326) Just like we do for extensions, list those which are supported and those that can be enabled with additional flags.
2024-07-10 15:43:18 +01:00
Profiles
========
Supported profile names can be passed using ``-march`` instead of a standard
ISA naming string. Currently supported profiles:
* ``rvi20u32``
* ``rvi20u64``
* ``rva20u64``
* ``rva20s64``
* ``rva22u64``
* ``rva22s64``
[RISCV][doc] Grammar fix Fixes 884a07fee0ba36649561003e36d197323380f3d2
2024-07-15 21:09:29 +01:00
Note that you can also append additional extension names to be enabled, e.g.
[RISCV][doc] Document profiles in RISCVUsage (#98326) Just like we do for extensions, list those which are supported and those that can be enabled with additional flags.
2024-07-10 15:43:18 +01:00
``rva20u64_zicond`` will enable the ``zicond`` extension in addition to those
in the ``rva20u64`` profile.
Profiles that are not yet ratified cannot be used unless
``-menable-experimental-extensions`` (or equivalent for other tools) is
specified. This applies to the following profiles:
* ``rva23u64``
* ``rva23s64``
* ``rvb23u64``
* ``rvb23s64``
* ``rvm23u32``
[docs] Add a RISC-V Usage page This follows the pattern set by e.g. SPIR-V, AMDGPU, and WebAssembly. For the moment, this page is fairly minimal stub. I mostly want a place to record which extensions we support, and when that support is not complete, a central place to note that. I'm deliberately starting with a subset of extensions which are pretty straight forward with only one case needing a detail note. I figure the partial support cases are going to need a bunch of discussion, and having each of them in their own review seemed worthwhile. Similarly, the experimental extensions probably fall into the same bucket of triggering a bunch of review discussion. Differential Revision: https://reviews.llvm.org/D133063
2022-09-06 12:06:53 -07:00
.. _riscv-extensions:
Extensions
==========
The following table provides a status summary for extensions which have been
ratified and thus have finalized specifications. When relevant, detailed notes
on support follow.
.. table:: Ratified Extensions by Status
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
================ =================================================================
Extension Status
================ =================================================================
``A`` Supported
[RISCV] Add B extension (#76893) It seems that we have `B` extension again: https://github.com/riscv/riscv-b According to the spec, `B` extension represents the collection of the `Zba`, `Zbb`, `Zbs` extensions. Though it hasn't been ratified, I set its version to `1.0`.
2024-06-11 14:06:23 +08:00
``B`` Supported
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``C`` Supported
``D`` Supported
``F`` Supported
``E`` Supported (`See note <#riscv-rve-note>`__)
``H`` Assembly Support
``M`` Supported
``Shcounterenw`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Shgatpa`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Shtvala`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Shvsatpa`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Shvstvala`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Shvstvecd`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Smaia`` Supported
[RISCV] Add smcdeleg and ssccfg extensions (#95163) Specification: https://github.com/riscv/riscv-isa-manual/blob/main/src/smcdeleg.adoc `Ssccfg` introduces one new CSR `scountinhibit`.
2024-06-12 12:43:39 +08:00
``Smcdeleg`` Supported
[RISCV] Add Smcsrind and Sscsrind extension (#93952) Specification link: https://github.com/riscv/riscv-isa-manual/blob/main/src/indirect-csr.adoc Some CSRs (`*ireg` and `*iselect`) in Smcsrind/Sscsrind extensions are originally defined as part of the Smaia/Ssaia extensions and are already supported in LLVM. The missing CSRs (`*ireg2` to `*ireg6` for `m`, `s`, and `vs`) are added in this PR.
2024-06-12 14:33:12 +08:00
``Smcsrind`` Supported
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Smepmp`` Supported
[RISCV] Add smstateen extension (#90818)
2024-05-02 09:12:44 -07:00
``Smstateen`` Assembly Support
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Ssaia`` Supported
[RISCV] Add smcdeleg and ssccfg extensions (#95163) Specification: https://github.com/riscv/riscv-isa-manual/blob/main/src/smcdeleg.adoc `Ssccfg` introduces one new CSR `scountinhibit`.
2024-06-12 12:43:39 +08:00
``Ssccfg`` Supported
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Ssccptr`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
[RISCV] Remove note of Sscofpmf and add a newline after FeatureStdExtSscofpmf (#83958) To address comments after committing #83831.
2024-03-05 14:26:54 +08:00
``Sscofpmf`` Assembly Support
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Sscounterenw`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
[RISCV] Add Smcsrind and Sscsrind extension (#93952) Specification link: https://github.com/riscv/riscv-isa-manual/blob/main/src/indirect-csr.adoc Some CSRs (`*ireg` and `*iselect`) in Smcsrind/Sscsrind extensions are originally defined as part of the Smaia/Ssaia extensions and are already supported in LLVM. The missing CSRs (`*ireg2` to `*ireg6` for `m`, `s`, and `vs`) are added in this PR.
2024-06-12 14:33:12 +08:00
``Sscsrind`` Supported
[RISCV] Remove experimental for Ssqosid ext (#105476) Ratified: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0
2024-08-21 16:42:16 +08:00
``Ssqosid`` Assembly Support
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Ssstateen`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Ssstrict`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Sstc`` Assembly Support
``Sstvala`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Sstvecd`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Ssu64xl`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Svade`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Svadu`` Assembly Support
``Svbare`` Assembly Support (`See note <#riscv-profiles-extensions-note>`__)
``Svinval`` Assembly Support
``Svnapot`` Assembly Support
``Svpbmt`` Supported
``V`` Supported
``Za128rs`` Supported (`See note <#riscv-profiles-extensions-note>`__)
``Za64rs`` Supported (`See note <#riscv-profiles-extensions-note>`__)
[RISCV] Bump Zaamo and Zalrsc to version 1.0 (#91556) The ratified information can be found here: https://wiki.riscv.org/display/HOME/Ratified+Extensions
2024-05-21 12:04:46 +08:00
``Zaamo`` Assembly Support
[RISCV] Remove experimental from Zabha (#93831) The Zabha extension was ratified in April 2024. Co-authored-by: Alexandre Ghiti <alexghiti@rivosinc.com>
2024-06-03 11:27:02 +02:00
``Zabha`` Supported
[RISCV] Bump Zaamo and Zalrsc to version 1.0 (#91556) The ratified information can be found here: https://wiki.riscv.org/display/HOME/Ratified+Extensions
2024-05-21 12:04:46 +08:00
``Zalrsc`` Assembly Support
[RISCV] Support Zama16b1p0 (#88474) This patch adds the support for Zama16b version 1.0, which has been added to RVA23U64 optional extensions recently
2024-04-16 23:36:27 -07:00
``Zama16b`` Supported (`See note <#riscv-profiles-extensions-note>`__)
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Zawrs`` Assembly Support
``Zba`` Supported
``Zbb`` Supported
``Zbc`` Supported
``Zbkb`` Supported (`See note <#riscv-scalar-crypto-note1>`__)
``Zbkc`` Supported
``Zbkx`` Supported (`See note <#riscv-scalar-crypto-note1>`__)
``Zbs`` Supported
``Zca`` Supported
``Zcb`` Supported
``Zcd`` Supported
``Zcf`` Supported
[RISCV] Add Zcmop and Zimop to RISCVUsage.rst. NFC (#88033) These extensions are ratified so they were removed from the experimental section, but not added to the non-experimental section.
2024-04-08 20:35:46 -07:00
``Zcmop`` Supported
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Zcmp`` Supported
``Zcmt`` Assembly Support
``Zdinx`` Supported
``Zfa`` Supported
[RISCV] Remove experimental for bf16 extensions (#97996) They are already ratified now.
2024-07-09 14:34:03 +08:00
``Zfbfmin`` Supported
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Zfh`` Supported
``Zfhmin`` Supported
``Zfinx`` Supported
``Zhinx`` Supported
``Zhinxmin`` Supported
``Zic64b`` Supported (`See note <#riscv-profiles-extensions-note>`__)
``Zicbom`` Assembly Support
``Zicbop`` Supported
``Zicboz`` Assembly Support
``Ziccamoa`` Supported (`See note <#riscv-profiles-extensions-note>`__)
``Ziccif`` Supported (`See note <#riscv-profiles-extensions-note>`__)
``Zicclsm`` Supported (`See note <#riscv-profiles-extensions-note>`__)
``Ziccrse`` Supported (`See note <#riscv-profiles-extensions-note>`__)
``Zicntr`` (`See Note <#riscv-i2p1-note>`__)
``Zicond`` Supported
``Zicsr`` (`See Note <#riscv-i2p1-note>`__)
``Zifencei`` (`See Note <#riscv-i2p1-note>`__)
``Zihintntl`` Supported
``Zihintpause`` Assembly Support
``Zihpm`` (`See Note <#riscv-i2p1-note>`__)
[RISCV] Add Zcmop and Zimop to RISCVUsage.rst. NFC (#88033) These extensions are ratified so they were removed from the experimental section, but not added to the non-experimental section.
2024-04-08 20:35:46 -07:00
``Zimop`` Supported
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Zkn`` Supported
``Zknd`` Supported (`See note <#riscv-scalar-crypto-note2>`__)
``Zkne`` Supported (`See note <#riscv-scalar-crypto-note2>`__)
``Zknh`` Supported (`See note <#riscv-scalar-crypto-note2>`__)
``Zksed`` Supported (`See note <#riscv-scalar-crypto-note2>`__)
``Zksh`` Supported (`See note <#riscv-scalar-crypto-note2>`__)
``Zk`` Supported
``Zkr`` Supported
``Zks`` Supported
``Zkt`` Supported
``Zmmul`` Supported
Reapply "[RISCV] Remove experimental from Ztso. (#96465)" This was reverted in f985a8826bfa4ca3d23e654185de35e30ea6dc79. Since that, the default WMO lowering has moved to A67 compatible, the ABI attribute emission has landed (off by default), and the LLD change to merge said attributes have landed. Our ztso lowering is believed to also be A67 compatible, and no known issues remain. Original commit message: Ztso 1.0 was ratified in January 2023. Documentation: https://github.com/riscv/riscv-isa-manual/blob/main/src/ztso-st-ext.adoc
2024-07-09 09:47:45 -07:00
``Ztso`` Supported
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Zvbb`` Assembly Support
``Zvbc`` Assembly Support
``Zve32x`` (`Partially <#riscv-vlen-32-note>`__) Supported
``Zve32f`` (`Partially <#riscv-vlen-32-note>`__) Supported
``Zve64x`` Supported
``Zve64f`` Supported
``Zve64d`` Supported
[RISCV] Remove experimental for bf16 extensions (#97996) They are already ratified now.
2024-07-09 14:34:03 +08:00
``Zvfbfmin`` Supported
``Zvfbfwma`` Supported
[RISCV] Add -march support for many of the S extensions mentioned in the profile specification. (#79399) This is a good portion of the extensions mentioned in the RVA23 profile here https://github.com/riscv/riscv-profiles/blob/main/rva23-profile.adoc I don't believe these add any new CSRs. Sstc does add new CSRs, but we already added them without the extension name a while back. I tried to keep the descriptions in RISCVFeatures.td fairly short since the strings show up in `-print-supported-extensions`.
2024-02-01 18:50:30 -08:00
``Zvfh`` Supported
``Zvkb`` Assembly Support
``Zvkg`` Assembly Support
``Zvkn`` Assembly Support
``Zvknc`` Assembly Support
``Zvkned`` Assembly Support
``Zvkng`` Assembly Support
``Zvknha`` Assembly Support
``Zvknhb`` Assembly Support
``Zvks`` Assembly Support
``Zvksc`` Assembly Support
``Zvksed`` Assembly Support
``Zvksg`` Assembly Support
``Zvksh`` Assembly Support
``Zvkt`` Assembly Support
``Zvl32b`` (`Partially <#riscv-vlen-32-note>`__) Supported
``Zvl64b`` Supported
``Zvl128b`` Supported
``Zvl256b`` Supported
``Zvl512b`` Supported
``Zvl1024b`` Supported
``Zvl2048b`` Supported
``Zvl4096b`` Supported
``Zvl8192b`` Supported
``Zvl16384b`` Supported
``Zvl32768b`` Supported
``Zvl65536b`` Supported
================ =================================================================
[docs] Add a RISC-V Usage page This follows the pattern set by e.g. SPIR-V, AMDGPU, and WebAssembly. For the moment, this page is fairly minimal stub. I mostly want a place to record which extensions we support, and when that support is not complete, a central place to note that. I'm deliberately starting with a subset of extensions which are pretty straight forward with only one case needing a detail note. I figure the partial support cases are going to need a bunch of discussion, and having each of them in their own review seemed worthwhile. Similarly, the experimental extensions probably fall into the same bucket of triggering a bunch of review discussion. Differential Revision: https://reviews.llvm.org/D133063
2022-09-06 12:06:53 -07:00
[docs][RISCV] Document status of Zicpo(m,p,z) extensions Unless I missed something when checking, we only support these in assembly. Given that, documenting them is a good opportunity to define support levels which will be useful for other extensions as well. Differential Revision: https://reviews.llvm.org/D133372
2022-09-06 13:35:39 -07:00
Assembly Support
LLVM supports the associated instructions in assembly. All assembly related tools (e.g. assembler, disassembler, llvm-objdump, etc..) are supported. Compiler and linker will accept extension names, and linked binaries will contain appropriate ELF flags and attributes to reflect use of named extension.
Supported
Fully supported by the compiler. This includes everything in Assembly Support, along with - if relevant - C language intrinsics for the instructions and pattern matching by the compiler to recognize idiomatic patterns which can be lowered to the associated instructions.
[RISCV] CodeGen of RVE and ilp32e/lp64e ABIs (#76777) This commit includes the necessary changes to clang and LLVM to support codegen of `RVE` and the `ilp32e`/`lp64e` ABIs. The differences between `RVE` and `RVI` are: * `RVE` reduces the integer register count to 16(x0-x16). * The ABI should be `ilp32e` for 32 bits and `lp64e` for 64 bits. `RVE` can be combined with all current standard extensions. The central changes in ilp32e/lp64e ABI, compared to ilp32/lp64 are: * Only 6 integer argument registers (rather than 8). * Only 2 callee-saved registers (rather than 12). * A Stack Alignment of 32bits (rather than 128bits). * ilp32e isn't compatible with D ISA extension. If `ilp32e` or `lp64` is used with an ISA that has any of the registers x16-x31 and f0-f31, then these registers are considered temporaries. To be compatible with the implementation of ilp32e in GCC, we don't use aligned registers to pass variadic arguments and set stack alignment\ to 4-bytes for types with length of 2*XLEN. FastCC is also supported on RVE, while GHC isn't since there is only one avaiable register. Differential Revision: https://reviews.llvm.org/D70401
2024-01-16 20:44:30 +08:00
.. _riscv-rve-note:
``E``
Support of RV32E/RV64E and ilp32e/lp64e ABIs are experimental. To be compatible with the implementation of ilp32e in GCC, we don't use aligned registers to pass variadic arguments. Furthermore, we set the stack alignment to 4 bytes for types with length of 2*XLEN.
[docs][RISCV] Add links to respective notes
2022-09-08 16:35:36 -07:00
.. _riscv-scalar-crypto-note1:
[docs] Fix a rebase error in 194900f
2022-09-08 16:04:03 -07:00
``Zbkb``, ``Zbkx``
Pattern matching support for these instructions is incomplete.
[docs][RISCV] Add links to respective notes
2022-09-08 16:35:36 -07:00
.. _riscv-scalar-crypto-note2:
[docs] Fix a rebase error in 194900f
2022-09-08 16:04:03 -07:00
``Zknd``, ``Zkne``, ``Zknh``, ``Zksed``, ``Zksh``
No pattern matching exists. As a result, these instructions can only be used from assembler or via intrinsic calls.
[docs][RISCV] Add links to respective notes
2022-09-08 16:35:36 -07:00
.. _riscv-vlen-32-note:
[docs] Add a RISC-V Usage page This follows the pattern set by e.g. SPIR-V, AMDGPU, and WebAssembly. For the moment, this page is fairly minimal stub. I mostly want a place to record which extensions we support, and when that support is not complete, a central place to note that. I'm deliberately starting with a subset of extensions which are pretty straight forward with only one case needing a detail note. I figure the partial support cases are going to need a bunch of discussion, and having each of them in their own review seemed worthwhile. Similarly, the experimental extensions probably fall into the same bucket of triggering a bunch of review discussion. Differential Revision: https://reviews.llvm.org/D133063
2022-09-06 12:06:53 -07:00
``Zve32x``, ``Zve32f``, ``Zvl32b``
[docs][RISCV] Document status of Zicpo(m,p,z) extensions Unless I missed something when checking, we only support these in assembly. Given that, documenting them is a good opportunity to define support levels which will be useful for other extensions as well. Differential Revision: https://reviews.llvm.org/D133372
2022-09-06 13:35:39 -07:00
LLVM currently assumes a minimum VLEN (vector register width) of 64 bits during compilation, and as a result ``Zve32x`` and ``Zve32f`` are supported only for VLEN>=64. Assembly support doesn't have this restriction.
[docs] Speculative link syntax fix
2023-02-13 09:42:25 -08:00
.. _riscv-i2p1-note:
[RISCV][docs] Describe status of zicsr and zifencei This has been a repeated point of recent confusion. There are a couple attempts in flight to change the way we handle the extensions, but for the moment, let's just document what's going on. Differential Revision: https://reviews.llvm.org/D14392
2023-02-13 09:07:28 -08:00
[Docs] Capitalize the first letter of Zi* extensions in RISCVUsage.rst. NFC
2024-01-24 21:40:28 -08:00
``Zicntr``, ``Zicsr``, ``Zifencei``, ``Zihpm``
[RISCV] Accept zicntr and zihpm command line options This change adds the definition of the two extensions, but does not either a) make any register definitions conditional on them or b) enabled the extensions by default. This is somewhat analogous to https://reviews.llvm.org/D143953, but with some key differences. The best discussion I can find on status is here: https://github.com/riscv/riscv-profiles/issues/43. These were removed between document version 2.1 and 2.2, but were not defined as new extensions in 2.2. That addition came later - in March 2022. According to https://drive.google.com/file/d/1qa57pePesOiDOrNzxuuGFhCL4Rbi9AYB/view these were ratified in March 2023. Reviewed By: asb, reames Differential Revision: https://reviews.llvm.org/D144215
2023-04-26 10:11:07 -07:00
Between versions 2.0 and 2.1 of the base I specification, a backwards incompatible change was made to remove selected instructions and CSRs from the base ISA. These instructions were grouped into a set of new extensions, but were no longer required by the base ISA. This change is partially described in "Preface to Document Version 20190608-Base-Ratified" from the specification document (the ``zicntr`` and ``zihpm`` bits are not mentioned). LLVM currently implements version 2.1 of the base specification. To maintain compatibility, instructions from these extensions are accepted without being in the ``-march`` string. LLVM also allows the explicit specification of the extensions in an ``-march`` string.
[RISCV][docs] Describe status of zicsr and zifencei This has been a repeated point of recent confusion. There are a couple attempts in flight to change the way we handle the extensions, but for the moment, let's just document what's going on. Differential Revision: https://reviews.llvm.org/D14392
2023-02-13 09:07:28 -08:00
[RISCV] Add support for new unprivileged extensions defined in profiles spec (#77458) This adds minimal support for 7 new unprivileged extensions that were defined as a part of the RISC-V Profiles specification here: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions * Ziccif: Main memory supports instruction fetch with atomicity requirement * Ziccrse: Main memory supports forward progress on LR/SC sequences * Ziccamoa: Main memory supports all atomics in A * Zicclsm: Main memory supports misaligned loads/stores * Za64rs: Reservation set size of 64 bytes * Za128rs: Reservation set size of 128 bytes * Zic64b: Cache block size isf 64 bytes As stated in the specification, these extensions don't add any new features but describe existing features. So this patch only adds parsing and subtarget features.
2024-01-19 06:57:06 +07:00
.. _riscv-profiles-extensions-note:
[RISCV] Support Zama16b1p0 (#88474) This patch adds the support for Zama16b version 1.0, which has been added to RVA23U64 optional extensions recently
2024-04-16 23:36:27 -07:00
``Za128rs``, ``Za64rs``, ``Zama16b``, ``Zic64b``, ``Ziccamoa``, ``Ziccif``, ``Zicclsm``, ``Ziccrse``, ``Shcounterenvw``, ``Shgatpa``, ``Shtvala``, ``Shvsatpa``, ``Shvstvala``, ``Shvstvecd``, ``Ssccptr``, ``Sscounterenw``, ``Ssstateen``, ``Ssstrict``, ``Sstvala``, ``Sstvecd``, ``Ssu64xl``, ``Svade``, ``Svbare``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
These extensions are defined as part of the `RISC-V Profiles specification <https://github.com/riscv/riscv-profiles/releases/tag/v1.0>`__. They do not introduce any new features themselves, but instead describe existing hardware features.
[RISCV] Add support for new unprivileged extensions defined in profiles spec (#77458) This adds minimal support for 7 new unprivileged extensions that were defined as a part of the RISC-V Profiles specification here: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions * Ziccif: Main memory supports instruction fetch with atomicity requirement * Ziccrse: Main memory supports forward progress on LR/SC sequences * Ziccamoa: Main memory supports all atomics in A * Zicclsm: Main memory supports misaligned loads/stores * Za64rs: Reservation set size of 64 bytes * Za128rs: Reservation set size of 128 bytes * Zic64b: Cache block size isf 64 bytes As stated in the specification, these extensions don't add any new features but describe existing features. So this patch only adds parsing and subtarget features.
2024-01-19 06:57:06 +07:00
[RISCV][doc] Add note to RISCVUsage about supported atomics ABIs (#103879) I've tried to avoid giving too much detailed explanation as the psABI docs are the better source for this.
2024-09-11 10:04:56 +01:00
Atomics ABIs
============
At the time of writing there are three atomics mappings (ABIs) `defined for RISC-V <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#tag_riscv_atomic_abi-14-uleb128version>`__. As of LLVM 19, LLVM defaults to "A6S", which is compatible with both the original "A6" and the future "A7" ABI. See `the psABI atomics document <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-atomic.adoc>`__ for more information on these mappings.
Note that although the "A6S" mapping is used, the ELF attribute recording the mapping isn't currently emitted by default due to a bug causing a crash in older versions of binutils when processing files containing this attribute.
[docs][RISCV] Document experimental extensions This adds a description of the currently existing experimental extensions. I took all information about versions and specifications from either the original commits, or current code. I'm not terribly familiar with any of these, so double checking my facts is much appreciated. Differential Revision: https://reviews.llvm.org/D133214
2022-09-08 12:25:07 -07:00
Experimental Extensions
=======================
LLVM supports (to various degrees) a number of experimental extensions. All experimental extensions have ``experimental-`` as a prefix. There is explicitly no compatibility promised between versions of the toolchain, and regular users are strongly advised *not* to make use of experimental extensions before they reach ratification.
The primary goal of experimental support is to assist in the process of ratification by providing an existence proof of an implementation, and simplifying efforts to validate the value of a proposed extension against large code bases. Experimental extensions are expected to either transition to ratified status, or be eventually removed. The decision on whether to accept an experimental extension is currently done on an entirely case by case basis; if you want to propose one, attending the bi-weekly RISC-V sync-up call is strongly advised.
[RISCV] Add support for RISC-V Pointer Masking (#79929) This patch implements the v0.8.1 specification. This patch reports version 0.8 in llvm since `RISCVISAInfo::ExtensionVersion` only has a `Major` and `Minor` version number. This patch includes includes support of the `Ssnpm`, `Smnpm`, `Smmpm`, `Sspm` and `Supm` extensions that make up RISC-V pointer masking. All of these extensions require emitting attribute containing correct `march` string. `Ssnpm`, `Smnpm`, `Smmpm` extensions introduce a 2-bit WARL field (PMM). The extension does not specify how PMM is set, and therefore this patch does not need to address this. One example of how it *could* be set is using the Zicsr instructions to update the PMM bits of the described registers. The full specification can be found at https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf
2024-02-05 13:56:25 -05:00
``experimental-ssnpm``, ``experimental-smnpm``, ``experimental-smmpm``, ``experimental-sspm``, ``experimental-supm``
[RISCV] Bump Pointer Masking extension version (#96715) These extensions had their version number bumped and still experimental (under public review). I didn't see anything in the [commit history](https://github.com/riscv/riscv-j-extension/commits/master/) since #79929 that would warrant a change to the implementation of pointer masking in the compiler.
2024-06-27 11:42:05 -04:00
LLVM implements the `v1.0.0-rc2 specification <https://github.com/riscv/riscv-j-extension/releases/tag/pointer-masking-v1.0.0-rc2>`__.
[RISCV] Add support for RISC-V Pointer Masking (#79929) This patch implements the v0.8.1 specification. This patch reports version 0.8 in llvm since `RISCVISAInfo::ExtensionVersion` only has a `Major` and `Minor` version number. This patch includes includes support of the `Ssnpm`, `Smnpm`, `Smmpm`, `Sspm` and `Supm` extensions that make up RISC-V pointer masking. All of these extensions require emitting attribute containing correct `march` string. `Ssnpm`, `Smnpm`, `Smmpm` extensions introduce a 2-bit WARL field (PMM). The extension does not specify how PMM is set, and therefore this patch does not need to address this. One example of how it *could* be set is using the Zicsr instructions to update the PMM bits of the described registers. The full specification can be found at https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf
2024-02-05 13:56:25 -05:00
[RISCV] Mark zacas as experimental again due to unresolved ABI issue (#99898) As discussed at the last sync-up call, mark Zacas as experimental until this ABI issue is resolved <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/444>. Don't return Zacas in getHostCPUFeatures (leaving a TODO there) as even if requesting detection of "native" features, the user likely doesn't want to automatically opt in to experimental codegen.
2024-07-23 08:06:15 +01:00
``experimental-zacas``
LLVM implements the `1.0 release specification <https://github.com/riscvarchive/riscv-zacas/releases/tag/v1.0>`__. amocas.w will be used for i32 cmpxchg. amocas.d will be used i64 cmpxchg on RV64. The compiler will not generate amocas.d on RV32 or amocas.q on RV64 due to ABI compatibilty. These can only be used in the assembler. The extension will be left as experimental until `an ABI issue <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/444>`__ is resolved.
[RISCV][MC] MC layer support for the experimental zalasr extension (#79911) This PR implements experimental support for the RISC-V Atomic Load-Acquire and Store-Release Extension (Zalasr). It has been approved to be pursued as a fast track extension (https://lists.riscv.org/g/tech-unprivileged/topic/arc_architecture_review/101951698), but has not yet been approved by ARC or ratified. See https://github.com/mehnadnerd/riscv-zalasr for draft spec. --------- Co-authored-by: brs <turtwig@utexas.edu> Co-authored-by: Philip Reames <preames@rivosinc.com>
2024-02-01 12:58:21 -06:00
``experimental-zalasr``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements the `0.0.5 draft specification <https://github.com/mehnadnerd/riscv-zalasr>`__.
[RISCV][MC] MC layer support for the experimental zalasr extension (#79911) This PR implements experimental support for the RISC-V Atomic Load-Acquire and Store-Release Extension (Zalasr). It has been approved to be pursued as a fast track extension (https://lists.riscv.org/g/tech-unprivileged/topic/arc_architecture_review/101951698), but has not yet been approved by ARC or ratified. See https://github.com/mehnadnerd/riscv-zalasr for draft spec. --------- Co-authored-by: brs <turtwig@utexas.edu> Co-authored-by: Philip Reames <preames@rivosinc.com>
2024-02-01 12:58:21 -06:00
[RISCV] Add MC layer support for Zicfiss. (#66043) The patch adds the instructions in Zicfiss extension. Zicfiss extension is to support shadow stack for control flow integrity. This patch is based on version [0.3.1]. [0.3.1]: https://github.com/riscv/riscv-cfi/releases/tag/v0.3.1
2023-12-30 15:40:20 +08:00
``experimental-zicfilp``, ``experimental-zicfiss``
[RISCV] Bump the version of Zicfilp/Zicfiss to 1.0 (#98891) Both of them are ratified now. https://wiki.riscv.org/display/HOME/Ratified+Extensions This patch does not set them to non-experimental, since Zicfilp lacks lld support and Zicfiss also lacks compiler-rt/libunwind support.
2024-07-16 14:38:08 +08:00
LLVM implements the `1.0 release specification <https://github.com/riscv/riscv-cfi/releases/tag/v1.0>`__.
[RISCV] Add MC layer support for Zicfilp. This adds extension Zicfilp and support pseudo instruction lpad. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D157362
2023-08-08 11:48:06 +08:00
[RISCV][MC] Support experimental extensions Zvbc32e and Zvkgs (#103709) These two extensions add addtional instructions for carryless multiplication with 32-bits elements and Vector-Scalar GCM instructions. Please see https://github.com/riscv/riscv-isa-manual/pull/1306.
2024-08-19 11:50:32 +08:00
``experimental-zvbc32e``, ``experimental-zvkgs``
LLVM implements the `0.7 release specification <https://github.com/user-attachments/files/16450464/riscv-crypto-spec-vector-extra_v0.0.7.pdf>`__.
[RISCV] Add CSRs and an instruction for Smctr and Ssctr extensions. (#105148) https://github.com/riscv/riscv-control-transfer-records/releases/tag/v1.0_rc3
2024-08-21 19:23:07 -07:00
``experimental-smctr``, ``experimental-ssctr``
LLVM implements the `1.0-rc3 specification <https://github.com/riscv/riscv-control-transfer-records/releases/tag/v1.0_rc3>`__.
[docs][RISCV] Document experimental extensions This adds a description of the currently existing experimental extensions. I took all information about versions and specifications from either the original commits, or current code. I'm not terribly familiar with any of these, so double checking my facts is much appreciated. Differential Revision: https://reviews.llvm.org/D133214
2022-09-08 12:25:07 -07:00
To use an experimental extension from `clang`, you must add `-menable-experimental-extensions` to the command line, and specify the exact version of the experimental extension you are using. To use an experimental extension with LLVM's internal developer tools (e.g. `llc`, `llvm-objdump`, `llvm-mc`), you must prefix the extension name with `experimental-`. Note that you don't need to specify the version with internal tools, and shouldn't include the `experimental-` prefix with `clang`.
[RISCV][docs] Add some wording around vendor extensions This adds an initial bit of policy around inclusion of vendor extensions. My intention here is to leave all of the actual decision making to a case by case decision on the regular sync calls, but to spell out some of the pieces we've discussed and (I think) have general agreement on. Differential Revision: https://reviews.llvm.org/D136968
2022-11-01 09:33:32 -07:00
Vendor Extensions
=================
[RISCV] Implement assembler support for XVentanaCondOps This change provides an implementation of the XVentanaCondOps vendor extension. This extension is defined in version 1.0.0 of the VTx-family custom instructions specification (https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf) by Ventana Micro Systems. In addition to the technical contribution, this change is intended to be a test case for our vendor extension policy. Once this lands, I plan to use this extension to prototype selection lowering to conditional moves. There's an RVI proposal in flight, and the expectation is that lowering to these and the new RVI instructions is likely to be substantially similar. Differential Revision: https://reviews.llvm.org/D137350
2022-11-14 08:29:55 -08:00
Vendor extensions are extensions which are not standardized by RISC-V International, and are instead defined by a hardware vendor. The term vendor extension roughly parallels the definition of a `non-standard` extension from Section 1.3 of the Volume I: RISC-V Unprivileged ISA specification. In particular, we expect to eventually accept both `custom` extensions and `non-conforming` extensions.
[RISCV][docs] Add some wording around vendor extensions This adds an initial bit of policy around inclusion of vendor extensions. My intention here is to leave all of the actual decision making to a case by case decision on the regular sync calls, but to spell out some of the pieces we've discussed and (I think) have general agreement on. Differential Revision: https://reviews.llvm.org/D136968
2022-11-01 09:33:32 -07:00
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
Inclusion of a vendor extension will be considered on a case by case basis. All proposals should be brought to the bi-weekly RISCV sync calls for discussion. For a general idea of the factors likely to be considered, please see the `Clang documentation <https://clang.llvm.org/get_involved.html>`__.
[RISCV][docs] Add some wording around vendor extensions This adds an initial bit of policy around inclusion of vendor extensions. My intention here is to leave all of the actual decision making to a case by case decision on the regular sync calls, but to spell out some of the pieces we've discussed and (I think) have general agreement on. Differential Revision: https://reviews.llvm.org/D136968
2022-11-01 09:33:32 -07:00
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
It is our intention to follow the naming conventions described in `riscv-non-isa/riscv-toolchain-conventions <https://github.com/riscv-non-isa/riscv-toolchain-conventions#conventions-for-vendor-extensions>`__. Exceptions to this naming will need to be strongly motivated.
[RISCV][docs] Add some wording around vendor extensions This adds an initial bit of policy around inclusion of vendor extensions. My intention here is to leave all of the actual decision making to a case by case decision on the regular sync calls, but to spell out some of the pieces we've discussed and (I think) have general agreement on. Differential Revision: https://reviews.llvm.org/D136968
2022-11-01 09:33:32 -07:00
[RISCV] Implement assembler support for XVentanaCondOps This change provides an implementation of the XVentanaCondOps vendor extension. This extension is defined in version 1.0.0 of the VTx-family custom instructions specification (https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf) by Ventana Micro Systems. In addition to the technical contribution, this change is intended to be a test case for our vendor extension policy. Once this lands, I plan to use this extension to prototype selection lowering to conditional moves. There's an RVI proposal in flight, and the expectation is that lowering to these and the new RVI instructions is likely to be substantially similar. Differential Revision: https://reviews.llvm.org/D137350
2022-11-14 08:29:55 -08:00
The current vendor extensions supported are:
[RISCV] Add vendor-defined XTHeadBa (address-generation) extension The vendor-defined XTHeadBa (predating the standard Zba extension) extension adds an address-generation instruction (th.addsl) with similar semantics as sh[123]add from Zba. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for XTHeadBa is available from: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D143029
2023-02-08 01:08:11 +01:00
``XTHeadBa``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadBa (address-generation) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTHeadBa (address-generation) extension The vendor-defined XTHeadBa (predating the standard Zba extension) extension adds an address-generation instruction (th.addsl) with similar semantics as sh[123]add from Zba. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for XTHeadBa is available from: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D143029
2023-02-08 01:08:11 +01:00
[RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension The vendor-defined XTHeadBb (predating the standard Zbb extension) extension adds some bit-manipulation extensions with somewhat similar semantics as some of the Zbb instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for XTHeadBb is available from: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da Depends on D143036 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D143439
2023-02-13 16:29:31 +01:00
``XTHeadBb``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadBb (basic bit-manipulation) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension The vendor-defined XTHeadBb (predating the standard Zbb extension) extension adds some bit-manipulation extensions with somewhat similar semantics as some of the Zbb instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for XTHeadBb is available from: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da Depends on D143036 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D143439
2023-02-13 16:29:31 +01:00
[RISCV] Add vendor-defined XTHeadBs (single-bit) extension The vendor-defined XTHeadBs (predating the standard Zbs extension) extension adds a bit-test instruction (th.tst) with similar semantics as bexti from Zbs. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for XTHeadBs is available from: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D143036
2023-02-13 16:10:11 +01:00
``XTHeadBs``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadBs (single-bit operations) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTheadCmo (Cache Management Operations) extension The vendor-defined XTHeadCmo (there are some similarities with the Zicbom standard extension) extension adds cache management instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a9ba8bc2d396fb8ae2b892f3bc6be8cdfe4b555c Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144496
2023-02-22 10:36:42 +01:00
[RISCV] Add vendor-defined XTheadCondMov (conditional move) extension The vendor-defined XTheadCondMov (somewhat related to the upcoming Zicond and XVentanaCondOps) extension add conditional move instructions with $rd being an input and an ouput instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73442230966a22b3238b2074691a71d7b4ed914a Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144681
2023-02-24 21:25:23 +01:00
``XTHeadCondMov``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadCondMov (conditional move) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTheadCondMov (conditional move) extension The vendor-defined XTheadCondMov (somewhat related to the upcoming Zicond and XVentanaCondOps) extension add conditional move instructions with $rd being an input and an ouput instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73442230966a22b3238b2074691a71d7b4ed914a Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144681
2023-02-24 21:25:23 +01:00
[RISCV] Add vendor-defined XTheadCmo (Cache Management Operations) extension The vendor-defined XTHeadCmo (there are some similarities with the Zicbom standard extension) extension adds cache management instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a9ba8bc2d396fb8ae2b892f3bc6be8cdfe4b555c Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144496
2023-02-22 10:36:42 +01:00
``XTHeadCmo``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadCmo (cache management operations) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTHeadBs (single-bit) extension The vendor-defined XTHeadBs (predating the standard Zbs extension) extension adds a bit-test instruction (th.tst) with similar semantics as bexti from Zbs. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for XTHeadBs is available from: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D143036
2023-02-13 16:10:11 +01:00
[RISCV] Add vendor-defined XTheadFMemIdx (FP Indexed Memory Operations) extension The vendor-defined XTHeadFMemIdx (no comparable standard extension exists at the time of writing) extension adds indexed load/store instructions for floating-point registers. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f511f80fa3fcaf6bcbe727fb902b8bd5ec8f9c20 Depends on D144249 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144647
2023-02-24 00:18:55 +01:00
``XTHeadFMemIdx``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadFMemIdx (indexed memory operations for floating point) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTheadFMemIdx (FP Indexed Memory Operations) extension The vendor-defined XTHeadFMemIdx (no comparable standard extension exists at the time of writing) extension adds indexed load/store instructions for floating-point registers. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f511f80fa3fcaf6bcbe727fb902b8bd5ec8f9c20 Depends on D144249 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144647
2023-02-24 00:18:55 +01:00
[RISCV] Add vendor-defined XTheadMAC (multiply-accumulate) extension The vendor-defined XTHeadMAC (no comparable standard extension exists at the time of writing) extension adds multiply accumulate instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=4041e11db3ec3611921d10150572a92689aa3154 Co-authored-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D143847
2023-02-14 19:43:00 +01:00
``XTheadMac``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the XTheadMac (multiply-accumulate instructions) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTheadMemIdx (Indexed Memory Operations) extension The vendor-defined XTHeadMemIdx (no comparable standard extension exists at the time of writing) extension adds indexed load/store instructions as well as load/store and update register instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=27cfd142d0a7e378d19aa9a1278e2137f849b71b Depends on D144002 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144249
2023-02-24 00:04:08 +01:00
``XTHeadMemIdx``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadMemIdx (indexed memory operations) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTheadMAC (multiply-accumulate) extension The vendor-defined XTHeadMAC (no comparable standard extension exists at the time of writing) extension adds multiply accumulate instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=4041e11db3ec3611921d10150572a92689aa3154 Co-authored-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D143847
2023-02-14 19:43:00 +01:00
[RISCV] Add vendor-defined XTheadMemPair (two-GPR Memory Operations) extension The vendor-defined XTHeadMemPair (no comparable standard extension exists at the time of writing) extension adds two-GPR load/store pair instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=6e17ae625570ff8f3c12c8765b8d45d4db8694bd Depends on D143847 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144002
2023-02-21 12:21:35 +01:00
``XTHeadMemPair``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadMemPair (two-GPR memory operations) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTheadMemPair (two-GPR Memory Operations) extension The vendor-defined XTHeadMemPair (no comparable standard extension exists at the time of writing) extension adds two-GPR load/store pair instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=6e17ae625570ff8f3c12c8765b8d45d4db8694bd Depends on D143847 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144002
2023-02-21 12:21:35 +01:00
[RISCV] Add vendor-defined XTheadSync (Multi-core synchronization) extension The vendor-defined XTheadSync (no comparable standard extension exists at the time of writing) extension adds multi-core synchronization instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=547c18d9bb95571261dbd17f4767194037eb82bd Depends on D144496 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144501
2023-02-22 10:58:50 +01:00
``XTHeadSync``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `the THeadSync (multi-core synchronization instructions) vendor-defined instructions specified in <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf>`__ by T-HEAD of Alibaba. Instructions are prefixed with `th.` as described in the specification.
[RISCV] Add vendor-defined XTheadSync (Multi-core synchronization) extension The vendor-defined XTheadSync (no comparable standard extension exists at the time of writing) extension adds multi-core synchronization instructions. It is supported by the C9xx cores (e.g., found in the wild in the Allwinner D1) by Alibaba T-Head. The current (as of this commit) public documentation for this extension is available at: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf Support for these instructions has already landed in GNU Binutils: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=547c18d9bb95571261dbd17f4767194037eb82bd Depends on D144496 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D144501
2023-02-22 10:58:50 +01:00
[RISCV] Implement assembler support for XTHeadVdot This patch implements the T-Head vendor extensions (XTHeadVdot), which is documented here, it's based on standard vector extension v1.0: https://github.com/T-head-Semi/thead-extension-spec
2022-11-09 16:17:20 +08:00
``XTHeadVdot``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the THeadV-family custom instructions specification <https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.0/xthead-2022-12-04-2.2.0.pdf>`__ by T-HEAD of Alibaba. All instructions are prefixed with `th.` as described in the specification, and the riscv-toolchain-convention document linked above.
[RISCV] Implement assembler support for XTHeadVdot This patch implements the T-Head vendor extensions (XTHeadVdot), which is documented here, it's based on standard vector extension v1.0: https://github.com/T-head-Semi/thead-extension-spec
2022-11-09 16:17:20 +08:00
[RISCV][NFC] Update RISCVUsage.rst to sort vendor extensions
2023-01-31 21:34:06 +01:00
``XVentanaCondOps``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the VTx-family custom instructions specification <https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf>`__ by Ventana Micro Systems. All instructions are prefixed with `vt.` as described in the specification, and the riscv-toolchain-convention document linked above. These instructions are only available for riscv64 at this time.
[RISCV] Support assembler and dis-assembler for VCIX extension. Spec: https://sifive.cdn.prismic.io/sifive/c3829e36-8552-41f0-a841-79945784241b_vcix-spec-software.pdf Differential Revision: https://reviews.llvm.org/D144530
2022-04-14 21:25:36 -07:00
``XSfvcp``
[RISCV] Update SiFive VCIX documentation link. NFC (#96986) The previous version of the document did not prefix the intrinsic names with `__riscv_`. That has been corrected now. We have always implemented the intrinsics with the `__riscv_` prefix so now the documentation matches our implementation. The document is now labeled as 1.1, but I have not changed the extension version in the compiler since it was only changing the intrinsic names.
2024-06-28 12:49:20 -07:00
LLVM implements `version 1.1.0 of the SiFive Vector Coprocessor Interface (VCIX) Software Specification <https://sifive.cdn.prismic.io/sifive/Zn3m1R5LeNNTwnLS_vcix-spec-software-v1p1.pdf>`__ by SiFive. All instructions are prefixed with `sf.vc.` as described in the specification, and the riscv-toolchain-convention document linked above.
[RISCV] Add support for XCVbitmanip extension in CV32E40P Implement XCVbitmanip intrinsics for CV32E40P according to the specification. This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj. Spec: https://github.com/openhwgroup/cv32e40p/blob/62bec66b36182215e18c9cf10f723567e23878e9/docs/source/instruction_set_extensions.rst Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D152915
2023-06-14 21:42:57 +08:00
[RISCV][SiFive] Add RISCVUsage for SiFive Intelligence Extensions (#84010)
2024-03-06 09:12:35 +08:00
``XSfvqmaccdod``, ``XSfvqmaccqoq``
LLVM implements `version 1.1.0 of the SiFive Int8 Matrix Multiplication Extensions Specification <https://sifive.cdn.prismic.io/sifive/1a2ad85b-d818-49f7-ba83-f51f1731edbe_int8-matmul-spec.pdf>`__ by SiFive. All instructions are prefixed with `sf.` as described in the specification linked above.
``Xsfvfnrclipxfqf``
LLVM implements `version 1.0.0 of the FP32-to-int8 Ranged Clip Instructions Extension Specification <https://sifive.cdn.prismic.io/sifive/0aacff47-f530-43dc-8446-5caa2260ece0_xsfvfnrclipxfqf-spec.pdf>`__ by SiFive. All instructions are prefixed with `sf.` as described in the specification linked above.
``Xsfvfwmaccqqq``
LLVM implements `version 1.0.0 of the Matrix Multiply Accumulate Instruction Extension Specification <https://sifive.cdn.prismic.io/sifive/c391d53e-ffcf-4091-82f6-c37bf3e883ed_xsfvfwmaccqqq-spec.pdf>`__ by SiFive. All instructions are prefixed with `sf.` as described in the specification linked above.
[RISCV] Add support for XCVbitmanip extension in CV32E40P Implement XCVbitmanip intrinsics for CV32E40P according to the specification. This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj. Spec: https://github.com/openhwgroup/cv32e40p/blob/62bec66b36182215e18c9cf10f723567e23878e9/docs/source/instruction_set_extensions.rst Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D152915
2023-06-14 21:42:57 +08:00
``XCVbitmanip``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the CORE-V Bit Manipulation custom instructions specification <https://github.com/openhwgroup/cv32e40p/blob/62bec66b36182215e18c9cf10f723567e23878e9/docs/source/instruction_set_extensions.rst>`__ by OpenHW Group. All instructions are prefixed with `cv.` as described in the specification.
[RISCV] Add support for XCVmac extension in CV32E40P Implement XCVmac intrinsics for CV32E40P according to the specification. This is the first commit of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. The patch-set aims at upstreaming the extensions on MC. The following will be on CodeGen, and the final patch-set will be on builtins if possible. The implemented version is on [0]. Contributors: @CharKeaney, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj Spec: https://github.com/openhwgroup/cv32e40p/blob/62bec66b36182215e18c9cf10f723567e23878e9/docs/source/instruction_set_extensions.rst [0] https://github.com/openhwgroup/corev-llvm-project Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D152821
2023-06-21 22:59:30 +08:00
[RISCV][MC] MC layer support for xcvmem and xcvelw extensions This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Several other extensions have been merged. Spec: https://github.com/openhwgroup/cv32e40p/blob/master/docs/source/instruction_set_extensions.rst Contributors: @CharKeaney, @jeremybennett, @lewis-revill, Nandni Jamnadas, @PaoloS, @simoncook, @xmj, @realqhc, @melonedo, @adeelahmad81299 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D158824
2023-11-16 09:34:38 +08:00
``XCVelw``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the CORE-V Event load custom instructions specification <https://github.com/openhwgroup/cv32e40p/blob/master/docs/source/instruction_set_extensions.rst>`__ by OpenHW Group. All instructions are prefixed with `cv.` as described in the specification. These instructions are only available for riscv32 at this time.
[RISCV][MC] MC layer support for xcvmem and xcvelw extensions This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Several other extensions have been merged. Spec: https://github.com/openhwgroup/cv32e40p/blob/master/docs/source/instruction_set_extensions.rst Contributors: @CharKeaney, @jeremybennett, @lewis-revill, Nandni Jamnadas, @PaoloS, @simoncook, @xmj, @realqhc, @melonedo, @adeelahmad81299 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D158824
2023-11-16 09:34:38 +08:00
[RISCV] Add support for XCVmac extension in CV32E40P Implement XCVmac intrinsics for CV32E40P according to the specification. This is the first commit of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. The patch-set aims at upstreaming the extensions on MC. The following will be on CodeGen, and the final patch-set will be on builtins if possible. The implemented version is on [0]. Contributors: @CharKeaney, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj Spec: https://github.com/openhwgroup/cv32e40p/blob/62bec66b36182215e18c9cf10f723567e23878e9/docs/source/instruction_set_extensions.rst [0] https://github.com/openhwgroup/corev-llvm-project Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D152821
2023-06-21 22:59:30 +08:00
``XCVmac``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the CORE-V Multiply-Accumulate (MAC) custom instructions specification <https://github.com/openhwgroup/cv32e40p/blob/4f024fe4b15a68b76615b0630c07a6745c620da7/docs/source/instruction_set_extensions.rst>`__ by OpenHW Group. All instructions are prefixed with `cv.mac` as described in the specification. These instructions are only available for riscv32 at this time.
[RISCV] Add support for custom instructions for Sifive S76. Support for below instruction is added 1. CFLUSH.D.L1 2. CDISCARD.D.L1 3. CEASE Additionally, Zihintpause extension is added to sifive s76 for pause instruction. Spec - https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D153370
2023-06-26 11:36:00 -07:00
[RISCV][MC] MC layer support for xcvmem and xcvelw extensions This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Several other extensions have been merged. Spec: https://github.com/openhwgroup/cv32e40p/blob/master/docs/source/instruction_set_extensions.rst Contributors: @CharKeaney, @jeremybennett, @lewis-revill, Nandni Jamnadas, @PaoloS, @simoncook, @xmj, @realqhc, @melonedo, @adeelahmad81299 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D158824
2023-11-16 09:34:38 +08:00
``XCVmem``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the CORE-V Post-Increment load and stores custom instructions specification <https://github.com/openhwgroup/cv32e40p/blob/master/docs/source/instruction_set_extensions.rst>`__ by OpenHW Group. All instructions are prefixed with `cv.` as described in the specification. These instructions are only available for riscv32 at this time.
[RISCV][MC] MC layer support for xcvmem and xcvelw extensions This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Several other extensions have been merged. Spec: https://github.com/openhwgroup/cv32e40p/blob/master/docs/source/instruction_set_extensions.rst Contributors: @CharKeaney, @jeremybennett, @lewis-revill, Nandni Jamnadas, @PaoloS, @simoncook, @xmj, @realqhc, @melonedo, @adeelahmad81299 Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D158824
2023-11-16 09:34:38 +08:00
[RISCV] Add support for XCValu extension in CV32E40P Implement XCValu intrinsics for CV32E40P according to the specification. This is a commit of the patch-set to upstream the 7 vendor specific extensions of CV32E40P. Contributors: @CharKeaney, Nandni Jamnadas, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D153748
2023-07-20 14:37:05 +08:00
``XCValu``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the Core-V ALU custom instructions specification <https://github.com/openhwgroup/cv32e40p/blob/4f024fe4b15a68b76615b0630c07a6745c620da7/docs/source/instruction_set_extensions.rst>`__ by Core-V. All instructions are prefixed with `cv.` as described in the specification. These instructions are only available for riscv32 at this time.
[RISCV] Add support for XCValu extension in CV32E40P Implement XCValu intrinsics for CV32E40P according to the specification. This is a commit of the patch-set to upstream the 7 vendor specific extensions of CV32E40P. Contributors: @CharKeaney, Nandni Jamnadas, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D153748
2023-07-20 14:37:05 +08:00
[RISCV] Add support for XCVsimd extension in CV32E40P Implement XCVsimd intrinsics for CV32E40P according to the specification. This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @PaoloS, @simoncook, @xmj. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D153721
2023-06-11 00:18:17 +08:00
``XCVsimd``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the CORE-V SIMD custom instructions specification <https://github.com/openhwgroup/cv32e40p/blob/cv32e40p_v1.3.2/docs/source/instruction_set_extensions.rst>`__ by OpenHW Group. All instructions are prefixed with `cv.` as described in the specification.
[RISCV] Add support for XCVsimd extension in CV32E40P Implement XCVsimd intrinsics for CV32E40P according to the specification. This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @PaoloS, @simoncook, @xmj. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D153721
2023-06-11 00:18:17 +08:00
[RISCV] Add support for XCVbi extension in CV32E40P Implement XCVbi intrinsics for CV32E40P according to the specification. This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @paolos, @simoncook, @xmj. bf2ad26b4ff856aab9a62ad168e6bdefeedc374f originally commited. e4777dc4b9cb371971523cc603e1b8a5c7255e7e reverted due to test failures caused by a merge conflict marker in llvm/test/CodeGen/RISCV/attributes that was accidentally checked in. This commit removed the conflict marker and recommitted. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D154412
2023-07-28 21:32:46 +08:00
``XCVbi``
[RISCV][Docs] Use double underscore for external links in RISCVUsage.rst. Using a single underscore creates a reference target. If the target name has the same name as another link, we get a "Duplicate target name" warning. This is currently happening for Ssqosid. Using __ prevents this. I've converted all links so no one trips over this in the future. One link was missing any underscores so wasn't a link at all in the generated html.
2024-02-06 10:38:06 -08:00
LLVM implements `version 1.0.0 of the CORE-V immediate branching custom instructions specification <https://github.com/openhwgroup/cv32e40p/blob/cv32e40p_v1.3.2/docs/source/instruction_set_extensions.rst>`__ by OpenHW Group. All instructions are prefixed with `cv.` as described in the specification. These instructions are only available for riscv32 at this time.
[RISCV] Add support for XCVbi extension in CV32E40P Implement XCVbi intrinsics for CV32E40P according to the specification. This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P. Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @paolos, @simoncook, @xmj. bf2ad26b4ff856aab9a62ad168e6bdefeedc374f originally commited. e4777dc4b9cb371971523cc603e1b8a5c7255e7e reverted due to test failures caused by a merge conflict marker in llvm/test/CodeGen/RISCV/attributes that was accidentally checked in. This commit removed the conflict marker and recommitted. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D154412
2023-07-28 21:32:46 +08:00
[RISCV] Add back SiFive's cdiscard.d.l1, cflush.d.l1, and cease instructions. (#83896) These were in LLVM 17 but removed from LLVM 18 due to an incorrect extension name being used. This restores them with new extension names that match SiFive's downstream compiler. The extension name has been used internally for some time. It uses XSiFive instead of XSf like the newer extensions. `cease` did not have an internal extension name so its using the `XSf` convention. The spec for the instructions is here https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf though the extension name is not listed. Column width in the extension printing had to be changed to accommodate a longer extension name.
2024-03-13 14:56:25 -07:00
``XSiFivecdiscarddlone``
LLVM implements `the SiFive sf.cdiscard.d.l1 instruction specified in <https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf>`_ by SiFive.
``XSiFivecflushdlone``
LLVM implements `the SiFive sf.cflush.d.l1 instruction specified in <https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf>`_ by SiFive.
``XSfcease``
LLVM implements `the SiFive sf.cease instruction specified in <https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf>`_ by SiFive.
[RISCV] Add QingKe "XW" compressed opcode extension (#97925) This extension consists of 8 additional 16-bit compressed forms for existing standard load/store opcodes. These opcodes are found in some RISC-V microcontrollers from WCH / Nanjing Qinheng Microelectronics. As discussed in the Discourse forums, this uses incompatible extension and opcode names vs the vendor binary toolchain. The chosen names instead follow the conventions for other vendor extensions listed on the "riscv-non-isa" project.
2024-07-11 04:10:02 +01:00
``Xwchc``
LLVM implements `the custom compressed opcodes present in some QingKe cores` by WCH / Nanjing Qinheng Microelectronics. The vendor refers to these opcodes by the name "XW".
[RISCV] Remove experimental from Vector Crypto extensions (#74213) The RISC-V vector crypto extensions have been ratified. This patch updates the Clang and LLVM support for these extensions to be non-experimental, while leaving the C intrinsics as experimental since the C intrinsics are not yet standardized. Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
2023-12-18 22:04:22 -08:00
Experimental C Intrinsics
=========================
In some cases an extension is non-experimental but the C intrinsics for that
extension are still experimental. To use C intrinsics for such an extension
from `clang`, you must add `-menable-experimental-extensions` to the command
line. This currently applies to the following extensions:
* ``Zvbb``
* ``Zvbc``
* ``Zvkb``
* ``Zvkg``
* ``Zvkn``
* ``Zvknc``
* ``Zvkned``
* ``Zvkng``
* ``Zvknha``
* ``Zvknhb``
* ``Zvks``
* ``Zvksc``
* ``Zvksed``
* ``Zvksg``
* ``Zvksh``
* ``Zvkt``
Reference in New Issue Copy Permalink