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.
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.
This is the second attempt. When parsing the target attribute
we should be letting cc1 features which don't correspond to
Extensions pass through to avoid errors like the following:
% cat neon.c
__attribute__((target("arch=armv8-a")))
uint64x2_t foo(uint64x2_t a, uint64x2_t b) { return veorq_u64(a, b); }
% clang --target=aarch64-linux-gnu -c neon.c
error: always_inline function 'veorq_u64' requires target feature
'outline-atomics', but would be inlined into function 'foo'
that is compiled without support for 'outline-atomics'
Co-authored-by: Tomas Matheson <Tomas.Matheson@arm.com>
This is a follow up to #92037, which moved the architecture information.
Generate the AArch64TargetParser CPUInfo from tablegen Processor defs using a
new tablegen emitter. Some basic error checking is added in the emitter to
ensure that duplicate features are not added to the Processor defs.
The generic CPU becomes an entry in tablegen.
Some CPU features which were present in the CPUInfo but absent from the tablegen
defs have been added to tablegen. FeatureCrypto is replaced with FeatureSHA2 and
FeatureAES. This changes a few of the tests.
This reverts commit 70510733af33c70ff7877eaf30d7718b9358a725.
The following code is now incorrectly rejected.
```
% cat neon.c
#include <arm_neon.h>
__attribute__((target("arch=armv8-a")))
uint64x2_t foo(uint64x2_t a, uint64x2_t b) {
return veorq_u64(a, b);
}
% newclang --target=aarch64-linux-gnu -c neon.c
neon.c:5:10: error: always_inline function 'veorq_u64' requires target feature 'outline-atomics', but would be inlined into function 'foo' that is compiled without support for 'outline-atomics'
5 | return veorq_u64(a, b);
| ^
1 error generated.
```
"+outline-atomics" seems misleading here.
My reverted attempt to decouple feature dependency expansion (see
#95056) made it evident that some features are still using the FMV
dependencies in the target attribute.
The original commit broke the llvm test suite. This was addressed here:
https://github.com/llvm/llvm-test-suite/pull/133. I am now relanding it.
This reverts commit 2cf14398c9341feddb419e7ff9c8c5623a3da3db since it
broke the llvm test suite:
SingleSource/UnitTests/AArch64/acle-fmv-features.c:59:9:
error: instruction requires: altnzcv
SingleSource/UnitTests/AArch64/acle-fmv-features.c:117:10:
error: instruction requires: aes
...
Looks like the FMV dependencies were used in the target attribute and
now features that are FMVOnly (have AEK_NONE) cannot be expanded in
parseTargetAttr using the ExtensionSet.
This suggests that either the tests are wrong (they are using an FMVOnly
feature in a target attribute), or that we need to turn the FMVOnly
features into Extensions (these two are tablegen classes).
The dependency expansion step which was introduced by FMV has been
erroneously used for non-FMV features, for example when parsing the
target attribute. The PR #93695 has rectified most of the tests which
were relying on dependency expansion of target features specified on the
-cc1 command line. In this patch I am decoupling the dependency
expansion of features specified on the target attribute from FMV.
To do that first I am expanding FMV dependencies before passing the list
of target features to initFeatureMap(). Similarly when parsing the
target attribute I am reconstructing an ExtensionSet from the list of
target features which was created during the command line option
parsing. The attribute parsing may toggle bits of that ExtensionSet and
at the end it is converted to a list of target features. Those are
passed to initFeatureMap(), which no longer requires an override.
A side effect of this refactoring is that features specified on the
target_version attribute now supersede the command line options, which
is what should be happening in the first place.
This change seeks to add support for vendor flavoured SPIRV - more
specifically, AMDGCN flavoured SPIRV. The aim is to generate SPIRV that
carries some extra bits of information that are only usable by AMDGCN
targets, forfeiting absolute genericity to obtain greater expressiveness
for target features:
- AMDGCN inline ASM is allowed/supported, under the assumption that the
[SPV_INTEL_inline_assembly](https://github.com/intel/llvm/blob/sycl/sycl/doc/design/spirv-extensions/SPV_INTEL_inline_assembly.asciidoc)
extension is enabled/used
- AMDGCN target specific builtins are allowed/supported, under the
assumption that e.g. the `--spirv-allow-unknown-intrinsics` option is
enabled when using the downstream translator
- the featureset matches the union of AMDGCN targets' features
- the datalayout string is overspecified to affix both the program
address space and the alloca address space, the latter under the
assumption that the
[SPV_INTEL_function_pointers](https://github.com/intel/llvm/blob/sycl/sycl/doc/design/spirv-extensions/SPV_INTEL_function_pointers.asciidoc)
extension is enabled/used, case in which the extant SPIRV datalayout
string would lead to pointers to function pointing to the private
address space, which would be wrong.
Existing AMDGCN tests are extended to cover this new target. It is
currently dormant / will require some additional changes, but I thought
I'd rather put it up for review to get feedback as early as possible. I
will note that an alternative option is to place this under AMDGPU, but
that seems slightly less natural, since this is still SPIRV, albeit
relaxed in terms of preconditions & constrained in terms of
postconditions, and only guaranteed to be usable on AMDGCN targets (it
is still possible to obtain pristine portable SPIRV through usage of the
flavoured target, though).
This patch generates ExtensionDependency pairs {Earlier, Later} inferred
by the 'Implies' field of every Extension defined in tablegen. Implied
Subtarget Features that are not Extensions are skipped.
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.
