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
This reapplies
195d8ac26d
[DirectX] Fix DXIL part header version encoding. The endian issue was
fixed by
f42117c851.
Move MinorVersion be the lower 8 bit.
Set DXIL version in DXContainerObjectWriter::writeObject.
Fixes#89952
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.
Currently, LLVM enables `-mbranch-protection=standard` as `bti+pac-ret`.
To align LLVM with the behaviour in GNU, this has been updated to
`bti+pac-ret+pc` when FEAT_PAuth_LR is enabled as an optional feature
via the `-mcpu=` options. If this is not enabled, then this will revert
to the existing behaviour.
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.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
This change set restores commit 080978dd2067d0c9ea7e229aa7696c2480d89ef1 that was reverted to address ASAN
failures and includes a fix for the ASAN failures.
Following is the description of the change:
An earlier commit provided a way to decouple DXIL version from Shader
Model version by representing the DXIL version as `SubArch` in the DXIL
Target Triple and adding corresponding valid DXIL Arch types.
This change constructs DXIL target triple with DXIL version that is
deduced from Shader Model version specified in the following scenarios:
1. When compilation target profile is specified:
For e.g., DXIL target triple `dxilv1.8-unknown-shader6.8-library` is
constructed when `-T lib_6_8` is specified.
2. When DXIL target triple without DXIL version is specified:
For e.g., DXIL target triple `dxilv1.8-pc-shadermodel6.8-library` is
constructed when `-mtriple=dxil-pc-shadermodel6.8-library` is specified.
Updated relevant HLSL tests that check for target triple.
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.
An earlier commit provided a way to decouple DXIL version from Shader
Model version by representing the DXIL version as `SubArch` in the DXIL
Target Triple and adding corresponding valid DXIL Arch types.
This change constructs DXIL target triple with DXIL version that is
deduced from Shader Model version specified in the following scenarios:
1. When compilation target profile is specified:
For e.g., DXIL target triple `dxilv1.8-unknown-shader6.8-library` is
constructed when `-T lib_6_8` is specified.
2. When DXIL target triple without DXIL version is specified:
For e.g., DXIL target triple `dxilv1.8-pc-shadermodel6.8-library` is
constructed when `-mtriple=dxil-pc-shadermodel6.8-library` is specified.
Updated relevant HLSL tests that check for target triple.
Validated that Clang (`check-clang`) and LLVM (`check-llvm`) regression
tests pass.
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.
Previously you got:
clang: error: invalid arch name 'rv64v', first letter should be 'e', 'i'
or 'g'
Which to me, unfamiliar with riscv, reads as if I should have used
"[eig]rv64v". Which is not what clang means.
Include the first bit in the error message to make this clearer:
clang: error: invalid arch name 'rv64v', first letter after 'rv64'
should be 'e', 'i' or 'g'
Previously we had an individiaul global array of implied extensions for
each extension that needed it. This allowed each array to have a
different length. Then we had a sorted table that stored pointers and
size for the indivual arrays keyed by the extension name.
This patch changes the sorted table to use multiple rows if multiple
extensions are implied. We use equal_range instead of lower_bound to
find all the rows that apply to a given extension.
The CombineIntoExts array was also modified to store only the extension
name that need to be combined. This extension name is looked up in the
implied table to find all the extensions it depends on.
This generates the SupportedExtensions and ImpliedExts information from
the RISCVExtension records found in RISCVFeatures.td.
Some of the extensions listed in the individual `ImpliedExts*` arrays
may be in a different, but the order in those array doesn't matter. I
manually verified the all the extensions were still present in each
array.
I've added the new information to the existing RISCVTargetParserDef.inc
and RISCVTargetDefEmitter.cpp so we don't need to re-parse the entirety
of RISCV.td a second time for a new file.
Introduce a mechanism to share data between the ARM and AArch64 backends and
TargetParser, to reduce duplication of code. This is similar to the current
RISC-V implementation.
The target tablegen file (in this case `ARM.td` or `AArch64.td`) is
processed during building of `TargetParser` to generate the following
files in the build tree:
- `build/include/llvm/TargetParser/ARMTargetParserDef.inc`
- `build/include/llvm/TargetParser/AArch64TargetParserDef.inc`
For now, the use of these generated files is limited to files _outside_
of `TargetParser`. The main reason for this is that the modifications to
`TargetParser` will require additional data added to the tablegen files,
which I want to split into separate PRs.
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.
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.
This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
This patch:
- Adds SPIR-V backend's registered generator magic number to the emitted
binary. The magic number consists of the generator ID (43) and LLVM
major version.
- Adds SPIR-V version to the binary.
- Allows reading the expected (maximum supported) SPIR-V version from
the target triple.
- Uses VersionTuple for representing versions throughout the backend's
codebase.
- Registers v1.6 for spirv32 and spirv64 triple.
See more: https://github.com/KhronosGroup/SPIRV-Headers/commit/7d500c
