This reverts commit b36fcf4f493ad9d30455e178076d91be99f3a7d8.
This reverts commit c11b6b1b8af7454b35eef342162dc2cddf54b4de.
This reverts commit 775148f2367600f90d28684549865ee9ea2f11be.
multiple bot build breakages, e.g. https://lab.llvm.org/buildbot/#/builders/3/builds/8076
Code cleanups for TableGen files, changes includes function names,
variable names and unused imports.
---------
Co-authored-by: Matt Arsenault <Matthew.Arsenault@amd.com>
Base on https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74.
This patch defines the groupid/bitmask in RISCVFeatures.td and generates
the corresponding table in RISCVTargetParserDef.inc.
The groupid/bitmask of extensions provides an abstraction layer between
the compiler and runtime functions.
This is just the TableGen-side changes, split out as the minimal
testable unit. It doesn't yet transition RVA23 and friends to be
experimental (and add the necessary other changes for this to work).
Although choosing not to emit the SupportedExperimentalProfiles array if
no experimental profiles are present isn't consistent with what we do
for experimental extensions, we need to do this in order to avoid adding
a warning for the empty array when building LLVM for as long as we don't
have any experimental profiles defined.
getAllDerivedDefinitions produces a fatal error if there are no
definitions. In practice this isn't much of a problem for
llvm/lib/Target/RISCV/*.td where it's hard to imagine not having at
least one of the required defitions. But it limits our ability to
structure and maintain tests (which is how I came across this issue).
This commit moves to using getAllDerivedDefinitionsIfDefined and aims to
skip emission of data structures that make no sense if no definitions
were found.
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.
We should remove the `experimental-` prefix when printing march
string.
We didn't meet this problem because there is no processor containing
experimental extensions.
Reviewers: fpetrogalli, asb, topperc
Reviewed By: topperc, asb
Pull Request: https://github.com/llvm/llvm-project/pull/90185
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.
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.
Instead of using RISCVISAInfo's extension information, use the extension
found in tblgen after #89326.
We still need to use RISCVISAInfo code to get the sorting rules for the
ISA string.
The ISA string we generate now is not quite the same extension we had
before. No implied extensions are included in the generate string unless
they are explicitly listed in RISCVProcessors.td. This primarily affects
Zicsr being implied by F, V implying Zve*, and Zvl*b implying a smaller
Zvl*b. All of these implication should be picked up when the string is
used by the frontend.
The benefit is that we get a more manageable ISA string for humans to
deal with.
This is a step towards generating RISCVISAInfo's extension list from
tblgen.
This is largely a revert of commit
e81796671890b59c110f8e41adc7ca26f8484d20.
As #88029 shows, there exists hardware that only supports unaligned
scalar.
I'm leaving how this gets exposed to the clang interface to a future
patch.
When we'd originally added unaligned-scalar-mem and
unaligned-vector-mem, they were separated into two parts under the
theory that some processor might implement one, but not the other. At
the moment, we don't have evidence of such a processor. The C/C++ level
interface, and the clang driver command lines have settled on a single
unaligned flag which indicates both scalar and vector support unaligned.
Given that, let's remove the test matrix complexity for a set of
configurations which don't appear useful.
Given these are internal feature names, I don't think we need to provide
any forward compatibility. Anyone disagree?
Note: The immediate trigger for this patch was finding another case
where the unaligned-vector-mem wasn't being properly serialized to IR
from clang which resulted in problems reproducing assembly from clang's
-emit-llvm feature. Instead of fixing this, I decided getting rid of the
complexity was the better approach.
This patch reference ac1ffd3caca12c254e0b8c847aa8ce8e51b6cfbf to suppot
a soft coding way to identify whether a cpu has a feature
`unaligned-scalar-mem` by `RISCVProcessors.td`.
This patch does not provide test case since there is no risc-v cpu
support `unaligned-scalar-mem` in llvm upstream now.
Using the correct feature name to detect 64bit this time. Previously,
I mistakenly compared the expected record name against a string inside
the record.
Instead of having separate feature bits, get information from march.
Invalid is now implied by empty march.
64-bit is now implied by march starting with "rv64".
Reviewed By: fpetrogalli
Differential Revision: https://reviews.llvm.org/D142230
As what has been mentioned in D137517, this patch is to simplify
processors definitions in RISCV.td. We don't have to specify march
string since we can generate it from target features.
Reviewed By: fpetrogalli, kito-cheng
Differential Revision: https://reviews.llvm.org/D141479
Rework the change to prevent build failures. NFCI.
The failing code was submitted as
cf7a8305a2b4ddfd299c748136cb9a2960ef7089 and reverted via
8bd65e535fb33bc48805bafed8217b16a853e158.
The rework in this new commit prevents failures like the following:
FAILED: tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Targets/RISCV.cpp.o
/usr/bin/c++ [bunch of non interesting stuff] -c <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp
In file included from <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp:19:
<path-to>/llvm-project/llvm/include/llvm/TargetParser/RISCVTargetParser.h:29:10: fatal error: llvm/TargetParser/RISCVTargetParserDef.inc: No such file or directory
29 | #include "llvm/TargetParser/RISCVTargetParserDef.inc"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These failures happen because the library LLVMTargetParser depends on
RISCVTargetParserTableGen, which is a tablegen target that generates
the list of CPUs in
llvm/TargetParser/RISCVTargetParserDef.inc. This *.inc file is
included by the public header file
llvm/TargetParser/RISCVTargetParser.h.
The header file llvm/TargetParser/RISCVTargetParser.h is also used in
components (clangDriver and clangBasic) that link into
LLVMTargetParser, but on some configurations such components might end
up being built before TargetParser is ready.
The fix is to make sure that clangDriver and clangBasic depend on the
tablegen target RISCVTargetParserTableGen, which generates the .inc
file whether or not LLVMTargetParser is ready.
WRT the original patch at https://reviews.llvm.org/D137517, this
commit is just adding RISCVTargetParserTableGen in the DEPENDS list of
clangDriver and clangBasic.
This patch removes the file `llvm/include/llvm/TargetParser/RISCVTargetParser.def` and replaces it with a tablegen-generated `.inc` file out of `llvm/lib/Target/RISCV/RISCV.td`.
The module system has been updated to make sure we can build clang/llvm with `-DLLVM_ENABLE_MODULES=On`
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D137517
