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 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.
This moves the architecture version, profile and extension information
into tablegen, and generates the TargetParser ArchInfo objects from
this data.
There are two lists of "dependencies" defined for each architecture: the
SubtargetFeature::Implies which controls which features are
automatically enabled in the backend when the corresponding architecture
SubtargetFeature is enabled; and the list of Extensions which are
enabled by default for this architecture. As far as I can tell, the idea
here is that the SubtargetFeature models the mandatory dependencies (although
they can still be disabled if desired) while the default extensions models
the typical use case for that architecture.
Generate TargetParser extension information from tablegen. This includes FMV extension information. FMV only extensions are represented by a separate tablegen class.
Use MArchName/ArchKindEnumSpelling to avoid renamings.
Cases where there is simply a case difference are handled by
consistently uppercasing the AEK_ name in the emitted code.
Remove some Extensions which were not needed.
These had AEK entries but were never actually used for anything.
They are not present in Extensions[] data.
Re-land 61b2a0e3336aaa0132bbed06dc185aca4ff5d2db. Some Windows builds
were failing because AArch64TargetParserDef.inc is a generated header
which is included transitively into some clang components, but this
information is not available to the build system and therefore there is
a missing edge in the dependency graph. This patch incorporates the
fixes described in ac1ffd3caca12c254e0b8c847aa8ce8e51b6cfbf/D142403.
Thanks to ExtensionSet::toLLVMFeatureList, all values of ArchExtKind
should correspond to a particular -target-feature. The valid values of
-target-feature are in turn defined by SubtargetFeature defs.
Therefore we can generate ArchExtKind from the tablegen data. This is
done by adding an Extension class which derives from SubtargetFeature.
Because the Has* FieldNames do not always correspond to the AEK_
names ("extensions", as defined in TargetParser), and AEK_ names do
not always correspond to -march strings, some additional enum entries
have been added to remap the names. I have renamed these to make the
naming consistent, but split them into a separate PR to keep the diff
reasonable (#90320)
Thanks to ExtensionSet::toLLVMFeatureList, all values of ArchExtKind
should correspond to a particular -target-feature. The valid values of
-target-feature are in turn defined by SubtargetFeature defs.
Therefore we can generate ArchExtKind from the tablegen data. This is
done by adding an Extension class which derives from SubtargetFeature.
Because the Has* FieldNames do not always correspond to the AEK_
names ("extensions", as defined in TargetParser), and AEK_ names do
not always correspond to -march strings, some additional enum entries
have been added to remap the names. I have renamed these to make the
naming consistent, but split them into a separate PR to keep the diff
reasonable (#90320)
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.
