RVA22 has retroactively been defined as including 'B' (as it's a
shorthand for Zba+Zbb+Zbs, which were previously explicitly enumerated)
and RV{A,B,M}23 are defined featuring B. We don't currently infer B
whenever Zba+Zbb+Zbs are present due to concerns about compatibility
with external assemblers such as gas.
We don't believe that adding B to RVA22 will cause issues for users who
(for instance) build with clang and assemble with binutils as looking at
the binutils commit history:
zic64b support was only committed in
25f05199bb7e35820c23e802424484accb7936b1 in July 2024
B support was committed in c144f638337944101131d9fe6de4ab908f6d4c2d in
May 2024
So given we emit zic64b anyway (as it has always been in the RVA22
spec), no binutils that would have previously successfully assembled our
rva22u64 output should fail due to the addition of 'B'.
This was introduced in the now-ratified RVA23 profile (and also added to
the RVA22 text) as a simple way of referring to H plus the set of
supervisor extensions required by RVA23.
https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc
This patch simply defines the extension. The next patch will adjust the
RVA23 profile to use it, and at that point I think we will be ready to
mark RVA23 as non-experimental.
Note that I haven't made it so if you enable all extensions that
constitute Sha, Sha is implied. Per #76893 (adding 'B'), the concern is
making this implication might break older external assemblers. Perhaps
this is less of a concern given the relative frequency of
`-march=${foo}_zba_zbb_zbs` vs the collection of H extensions. If we did
want to add that implication, we'd probably want to add it in a separate
patch so it can be easily reverted if found to cause problems.
This commit has completed the Extension for Resumable Non Maskable
Interrupts, adding four CRSs and one Trap-Return instruction.
Specification link:["Smrnmi"
Extension](https://github.com/riscv/riscv-isa-manual/blob/main/src/rnmi.adoc)
---------
Co-authored-by: Sam Elliott <sam@lenary.co.uk>
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.
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.
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.
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
With the tag merging in place, we can safely change the default for
+seq-cst-trailing-fence to the default, according to the recommendation
in
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-atomic.adoc
This patch changes the default for the feature flag, and moves to more
consistent naming with respect to existing features.
This was reverted with https://github.com/llvm/llvm-project/pull/84597,
because ld.bfd would segfault with unknown riscv attributes. Now that
attributes emission is guarded with a backend flag,
`--riscv-abi-attributes`, this should be safe to reland, since it won't
introduce abi tags unless the user opts into them.
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.
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.
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`.
As discussed in the last sync-up call, because these profiles are not
yet finalised they shouldn't be exposed to users unless they opt-in to
them (much like experimental extensions). We may later want to add a
more specific flag, but reusing `-menable-experimental-extensions`
solves the immediate problem.
This is implemented using the new support for marking profiles s
experimental added in #91993 to move the unratified profiles to
RISCVExperimentalProfile and making the necessary changes to logic in
RISCVISAInfo to handle this.
This may simplify the usage of tools like `opt`, `llc`, etc.
Reviewers: michaelmaitland, 4vtomat, preames, asb
Reviewed By: michaelmaitland, preames, 4vtomat
Pull Request: https://github.com/llvm/llvm-project/pull/84877
This reverts commit 9221f3af8f832d990be986c05d964ad37e5a2356.
As reported
<https://github.com/llvm/llvm-project/pull/84597#issuecomment-2079128332>
and confirmed by me locally, adding these attributes causes current GNU
ld to segfault when processing the input. Reverted so we can discuss
the best next step.
With the tag merging in place, we can safely change the default for
+seq-cst-trailing-fence to the default, according to the recommendation
in
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-atomic.adoc
This tag changes the default for the feature flag, and moves to more
consistent naming with respect to existing features.
This patch adds support for the `atomic_abi` attribute, specifid in
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#tag_riscv_atomic_abi-14-uleb128version.
The atomics_abi tag merging is conducted as follows:
- UNKNOWN is safe to merge with all other values.
- A6C is compatible with A6S, and results in the A6C ABI.
- A6C is incompatible with A7, and results in an error.
- A6S and A7 are compatible, and merging results in the A7 ABI.
Note: the A7 is not yet supported in either LLVM or in any current
hardware,
and is therefore ommited from attribute generation in
RISCVTargetStreamer.
Zabha and Zacas are both documented as depending on Zaamo. I'm
hesitant to make them imply Zaamo instead.
So remove the implication and replace with a check that either
A or Zaamo is enabled.
There is no implies rule in RISCVISAInfo.cpp so this makes them
consistent.
Soon RISCVFeatures.td will be used to generate RISCVISAInfo.cpp so
it won't be possible to mismatch.
