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>
Add support for the following Armv9.6-A memory systems extensions:
FEAT_LSUI - Unprivileged Load Store
FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation
FEAT_PCDPHINT - Producer-Consumer Data Placement Hints
FEAT_SRMASK - Bitwise System Register Write Masks
as documented here:
https://developer.arm.com/documentation/109697/2024_09/Feature-descriptions/The-Armv9-6-architecture-extension
Co-authored-by: Jonathan Thackray <jonathan.thackray@arm.com>
---------
Co-authored-by: Jonathan Thackray <jonathan.thackray@arm.com>
This patch implements new features introduced in 2024 release of ARM ISA
and creates predicates, which will be used by new instructions.
Co-authored-by: Caroline Concatto caroline.concatto@arm.com
Co-authored-by: Spencer Abson spencer.abson@arm.com
Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.
An open question is whether we can backport this to LLVM 19.x. After
all, adding new triplets to Triple sounds like an ABI change — though I
suppose we can minimize the risk of breaking something if we move new
enum values to the very end.
This adds support for:
* `muslabin32` (MIPS N32)
* `muslabi64` (MIPS N64)
* `muslf32` (LoongArch ILP32F/LP64F)
* `muslsf` (LoongArch ILP32S/LP64S)
As we start adding glibc/musl cross-compilation support for these
targets in Zig, it would make our life easier if LLVM recognized these
triples. I'm hoping this'll be uncontroversial since the same has
already been done for `musleabi`, `musleabihf`, and `muslx32`.
I intentionally left out a musl equivalent of `gnuf64` (LoongArch
ILP32D/LP64D); my understanding is that Loongson ultimately settled on
simply `gnu` for this much more common case, so there doesn't *seem* to
be a particularly compelling reason to add a `muslf64` that's basically
deprecated on arrival.
Note: I don't have commit access.
This is a partial revert of c66e1d6f3429. Even though that
allowed us to declare v9.2-a support without picking up SVE2
in both the backend and the driver, the frontend itself still
enabled SVE via the arch version's default extensions.
Avoid that by reverting back to v8.7-a while we look into
longer-term solutions.
This adds a check that all ExtensionWithMArch which are marked as
implied features for an architecture are also present in the list of
default features. It doesn't make sense to have something mandatory but
not on by default.
There were a number of existing cases that violated this rule, and some
changes to which features are mandatory (indicated by the Implies
field).
This resulted in a bug where if a feature was marked as `Implies` but
was not added to `DefaultExt`, then for `-march=base_arch+nofeat` the
Driver would consider `feat` to have never been added and therefore
would do nothing to disable it (no `-target-feature -feat` would be
added, but the backend would enable the feature by default because of
`Implies`). See
clang/test/Driver/aarch64-negative-modifiers-for-default-features.c.
Note that the processor definitions do not respect the architecture
DefaultExts. These apply only when specifying `-march=<some architecture
version>`. So when a feature is moved from `Implies` to `DefaultExts` on
the Architecture definition, the feature needs to be added to all
processor definitions (that are based on that architecture) in order to
preserve the existing behaviour. I have checked the TRMs for many cases
(see specific commit messages) but in other cases I have just kept the
current behaviour and not tried to fix it.
Implement FEAT_SME_B16B16 to enable ZA-targeting non-widening SME
BFloat16 instructions. Remove the now redundant FEAT_B16B16 which has
been replaced by FEAT_SVE_B16B16 and FEAT_SME_B16B16 (this commit), see
https://github.com/llvm/llvm-project/pull/101480/ for the details and
reasoning of this change to LLVM.
FEAT_SME_B16B16 is documented under the latest Armv9.4 feature
documentation:
https://developer.arm.com/documentation/109697/0100/Feature-descriptions/The-Armv9-4-architecture-extensio
- Changes to Clang AArch64 frontend
- Change target guard of SME2 ZA-targeting non-widening BFloat16
intrinsics to 'sme-b16b16'
- Changes to LLVM AArch64 backend
- llvm/lib/Target/AArch64/AArch64Features.td
- Create FeatureSMEB16B16, which implies FeatureSME2 and
FeatureSVEB16B16
- Remove FeatureB16B16
- Fix description of FeatureSVEB16B16
- llvm/lib/Target/AArch64/AArch64InstrInfo.td
- Create HasSMEB16B16 predicate
- llvm/lib/Target/AArch64/AArch64SMEInstrInfo.td
- Change predictication of SME2 ZA-targeting non-widening BFloat16
instructions to new HasSMEB16B16
- llvm/lib/Target/AArch64/AArch64.td
- Add HasSMEB16B16 to SME2Unsupported (FEAT_SME_B16B16 implies
FEAT_SME2)
- llvm/lib/AArch64/AsmParser/AArch64AsmParser.cpp
- Remove flag 'b16b16' mapping to removed FeatureB16B16
- Add flag 'sme-b16b16' mapping to new FeatureSMEB16B16
- Changes to LLVM unit tests
- llvm/unittests/TargetParser/TargetParserTest.cpp
- Add new sme-b16b16 flag to existing target parser tests
- Add tests for the sme-b16b16 dependencies:
- 'sme-b16b16' should enable 'sme2', 'sve-b16b16'. - Remove 'b16b16'
from bf16 dependency test
- Added MC tests
- llvm/test/MC/AArch64/SME2p1
- To ensure that ZA-targeting multi-vector non-widening BFloat16
instructions are enabled by +sme-b16b16, and that this feature is
removed by +nosme-b61b6.
- Modidified tests
- All CodeGen, Semantic, and MC tests that are effected by the removal
of 'b16b16', have been modified to supply and/or expect 'sme-b16b16'
where appropriate.
This patch adds FeatureSVEB16B16 to the AArch64 backend in order to
represent the new behavior of FEAT_SVE_B16B16 (as described in the
latest [Armv9.4 extensions
documentation](https://developer.arm.com/documentation/109697/0100/Feature-descriptions/The-Armv9-4-architecture-extension?lang=en#md461-the-armv94-architecture-extension__FEAT_SVE_B16B16))
as well as a 'sve-b16b16' flag to enable it.
The predication of non-widening SVE BFloat16 instructions has changed to
require this feature, instead of the previously required and
soon-to-be-removed FeatureB16B16 which is enabled by the 'b16b16' flag.
Therefore, this change weakens the 'b16b16' flag in favour of
'sve-b16b16'. Existing tests that are effected by this have been
modified to use and/or expect 'sve-b16b16', and new tests have been
added to verify the behavior and implementation of 'sve-b16b16'.
This patch is in response to the response to the following changes.
The architecture features previously enabled by FEAT_SVE_B16B16 have
been relaxed such that it now implements:
- With FEAT_SVE2 : SVE non-widening BFloat16 instructions in
Non-streaming SVE mode
- With FEAT_SME2: SVE non-widening BFloat16 instructions when the
PE is in Streaming SVE mode and SME
Z-targeting multi-vector non-widening BFloat16 instructions.
- **It no longer implements** SME ZA-targeting non-widening
BFloat16 instructions.
The SME ZA-targeting non-widening BFloat16 instructions are implemented
by the new FEAT_SME_B16B16, **this patch does not change how this
architecture feature is enabled** ('+b16b16+sme2'). Only those that are
implemented by FEAT_SVE_B16B16 have been changed to require 'sve-b16b16'
instead of 'b16b16'.
New flags must be created to represent FEAT_SVE_B16B16 and
FEAT_SME_B16B16:
- 'sve-b16b16' enables the updated FEAT_SVE_B16B16 (described
here)
- 'sme-b16b16' will enable the new FEAT_SME_B16B16
- **This patch includes 'sve-b16b16' only**
A future patch will add 'sme-b16b16', SME ZA-targeting non-widening
BFloat16 instructions would then be guarded by '+sme-b16b16+sme2', and
'b16b16' can be removed.
We added FPAC recently in d7e8a7487cd7 to allow ptrauth codegen to rely
on the cpu auth failure checks rather than emitting its own auth failure
check/brk sequence.
Add it to the Apple processors that do have it: A15, A16, A17, M4.
While there, tweak the description to refer to Armv8.3-A rather than
v8.3-A, matching the other features.
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.
When `pauthtest` is either passed as environment part of AArch64 Linux
triple
or passed via `-mabi=`, enable the following ptrauth flags:
- `intrinsics`;
- `calls`;
- `returns`;
- `auth-traps`;
- `vtable-pointer-address-discrimination`;
- `vtable-pointer-type-discrimination`;
- `init-fini`.
Some related stuff is still subject to change, and the ABI itself might
be changed, so end users are not expected to use this and the ABI name
has 'test' suffix.
If `-mabi=pauthtest` option is used, it's normalized to effective
triple.
When the environment part of the effective triple is `pauthtest`, try
to use `aarch64-linux-pauthtest` as multilib directory.
The following is not supported:
- combination of `pauthtest` ABI with any branch protection scheme
except BTI;
- explicit set of environment part of the triple to a value different
from `pauthtest` in combination with `-mabi=pauthtest`;
- usage on non-Linux OS.
---------
Co-authored-by: Anatoly Trosinenko <atrosinenko@accesssoftek.com>
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.
But since SVE and friends have been added to the default extensions
list, and every CPU was opted into those extensions by default, we
couldn't correctly announce its architecutral version to the backend.
Additionally, we FEAT_MEC from llvm's "required" list for v9.0 to the
optional list for v9.2, as the spec considers it optional, and M4 does
not implement it. Similarly, fixes up several bugs w.r.t. FEAT_RME.
As a drive-by, I noticed that saphira did not have an
AArch64CPUTestParams entry, and thus added one.
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.
bb83a3d introduced `--print-enabled-extensions` command line option for
AArch64. This patch introduces RISC-V support for this option. This patch
adds documentation for this option.
`riscvExtensionsHelp` is renamed to `printSupportedExtensions` to by
synonymous with AArch64 and so it is clear what that function does.
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
For both overloads, we were printing the bit-pattern for ExpectedFlags
twice. While we're here, also add a convenience line that highlights the
difference between the two sets.
For AArch64, we have existing tests for `--print-enabled-extensions` for
each architecture. However:
- These are added to the end of the existing tests which check for
`"-target-feature"`, which complicates them slightly.
- They do not test the descriptions printed next to each feature.
- Part of the output was tested separately in `TargetParserTest`.
- We did not have _any_ tests of this output for CPUs (only for
architectures).
Similarly, the tests for `--print-supported-extensions` do not give
complete coverage of either the full list of features or the
descriptions.
In my opinion we should be testing the full output, as this is what the
user sees. Descriptions and formatting can contain errors and be
accidentally broken.
There were a couple of cases where this field was just plain wrong
because we weren't actually testing against it. Instead, drop the
`CPUAttr` field on AArch64 tests.
This isn't used in tree, and thus I don't know what the expectations for
its behavior really are. The original usage of this feature has been replaced
by parseNormalizedArchString.
This introduces the new `--print-enabled-extensions` command line option
to AArch64, which prints the list of extensions that are enabled for the
target specified by the combination of `--target`/`-march`/`-mcpu`
values.
The goal of the this option is both to enable the manual inspection of
the enabled extensions by users and to enhance the testability of
architecture versions and CPU targets implemented in the compiler.
As part of this change, a new field for `FEAT_*` architecture feature
names was added to the TableGen entries. The output of the existing
`--print-supported-extensions` option was updated accordingly to show
these in a separate column.
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.
