S.substr(N) is simpler than S.slice(N, StringRef::npos) and
S.slice(N, S.size()). Also, substr is probably better recognizable
than slice thanks to std::string_view::substr.
The spec can be found at
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74.
1. Add the new extension GroupID/Bitmask with latest hwprobe key.
2. Update the `initRISCVFeature `
3. Update `EmitRISCVCpuSupports` due to not only group0 now.
This implements the __builtin_cpu_init and __builtin_cpu_supports
builtin routines based on the compiler runtime changes in
https://github.com/llvm/llvm-project/pull/85790.
This is inspired by https://github.com/llvm/llvm-project/pull/85786.
Major changes are a) a restriction in scope to only the builtins (which
have a much narrower user interface), and the avoidance of false
generality. This change deliberately only handles group 0 extensions
(which happen to be all defined ones today), and avoids the tblgen
changes from that review.
I don't have an environment in which I can actually test this, but @BeMg
has been kind enough to report that this appears to work as expected.
Before this can make it into a release, we need a change such as
https://github.com/llvm/llvm-project/pull/99958. The gcc docs claim that
cpu_support can be called by "normal" code without calling the cpu_init
routine because the init routine will have been called by a high
priority constructor. Our current compiler-rt mechanism does not do
this.
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.
lld was using RISCVISAInfo(unsigned XLen,
RISCVISAUtils::OrderedExtensionMap &Exts). This required a call to
RISCVISAInfo::postProcessAndChecking to validate the RISCVISAInfo that
was created. This exposes too much about RISCVISAInfo to lld.
Replace with a new RISCVISAInfo::createFromExtMap that is responsible
for creating the object and calling postProcessAndChecking.
Use the Exts map directly instead of adding to a temporary MapVector
first.
There are a couple functional change from this.
-If an unknown extension is duplicated, we will now print an error for
it being unknown instead of an error for it being duplicated.
-If an unknown extension is followed by an underscore with no extension after
it, we will error for the unknown extension instead of the dangling
underscore.
These don't seem like serious changes to me. I've updated tests
accordingly.
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.
Merge handling of the baseline ISA into the switch that checks if
the baseline is valid.
Invert a condition to allow a better early out to reduce curly braces.
We can edit the map directly at the caller. Many of the callers
already directly call contains or erase on the map. So there's no
good reason to have a wrapper for adding to the map.
We don't need to use a SmallSetVector to keep track of the worklist.
We only insert into the worklist if the extension is not already
in the Exts map. We immediately add it the Exts map at the same
time we add it to the worklist. If we encounter the extension again
it will already be in Exts so we won't try to add it to the worklist
again. We can just use a SmallVector for the Worklist.
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.
After patch https://github.com/llvm/llvm-project/pull/88805
`I` Ext will be added automatically when we running the command like
`./build/bin/llc -mtriple=riscv32 -mattr=+e -target-abi ilp32e
-verify-machineinstrs llvm/test/CodeGen/RISCV/zcmp-additional-stack.ll`
it will generate
```
.text
.attribute 4, 16
.attribute 5, "rv32i2p1_e2pe"
.file "zcmp-additional-stack.ll"
.globl func # -- Begin function func
.p2align 1
.type func,@function
```
This patch reset the I ext in FeatureBit when `+e` has been specify
hasExtension checks if the extension name is a known extension name.
That should always be true for the extensions listed here so we can
skip that check.
We can extract each extension as we process them without much
complexity.
I changed the error message for cases where there are double underscores
or a trailing underscore. I think this is an improvement over the
previous error.
hasExtension check isSupportedExtension before the map lookup. All
of the extensions we check for in updateCombination should be valid
extension names so we can bypass that to save some time.
We can use a SmallVector<StringRef>.
Adjust the code so we check for empty strings in the loop instead of
making a copy of the vector returned from StringRef::split.
This overlaps with #91532 which also removed the std::vector, but
that PR may be more controversial.
This detects the same extension name being added twice. Mostly I'm
worried about the case that the same string appears with two different
versions. We will only preserve one of the versions.
We could allow the same version to be repeated, but that doesn't seem
useful at the moment.
I've updated addExtension to use map::emplace instead of
map::operator[]. This means we only keep the first version if there are
duplicates. Previously we kept the last version, but that shouldn't matter
now that we don't allow duplicates. parseArchString already doesn't allow
duplicates.
Extensions starting with 's' or 'x' should always be followed by an
alphabetical character. I don't know of any crashes from this currently,
but it seemed better to be defensive.
If 'z' is given as the complete extension name or with a digit after it,
it will crash in the extension map compare function. Check for these
cases and give an error.
Previously we only rejected upper case characters. We should instead
reject anything except lower case, numbers, and underscore. Other
characters will likely confuse the extension sorting.
I tried also printing the -march they correspond to, but it seemed
overly verbose and caused line wraps. It might be better if we remove
the versions numbers from the string or did a more intelligent line
wrap.
As the list of profiles grow, this will be a more efficient lookup.
Because the profile name is a prefix of the Arch string, we use
upper_bound to find the first profile that definitely comes after the
Arch string. If that isn't the first supported profile, we move back 1
profile and see if that profile is a prefix of our Arch string.
Instead of hardcoding the 4 current profile prefixes, treat profile
selection as a fallback if we don't find "rv32" or "rv64".
Update the error message accordingly.
We weren't fully checking that we parsed Zve*x/f/d correctly. This could
break if new extension is added that starts with Zve.
We were assuming the Zve64d is present whenever V is so we only
inferred from Zve*. It's more correct to infer ELEN from V itself too.
This replaces some starts_with calls wth consume_front. This allows us
to remove a later assumption that prefix was 4 characters. We would
eventually need to fix this anyway if we ever support rv128.
Noticed while reviewing the RISCVISAInfo code for other reasons.
