mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-29 21:06:05 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/llvm/utils/TableGen/RISCVTargetDefEmitter.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

258 lines
8.3 KiB
C++
Raw Normal View History

[RISCV] Replace RISCV -> RISC-V in comments. NFC To be consistent with RISC-V branding guidelines https://riscv.org/about/risc-v-branding-guidelines/ Think we should be using RISC-V where possible. More patches will follow. Reviewed By: asb Differential Revision: https://reviews.llvm.org/D146449
2023-03-27 09:15:53 -07:00
//===- RISCVTargetDefEmitter.cpp - Generate lists of RISC-V CPUs ----------===//
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
//
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
// This tablegen backend emits the include file needed by RISCVTargetParser.cpp
// and RISCVISAInfo.cpp to parse the RISC-V CPUs and extensions.
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
//
//===----------------------------------------------------------------------===//
[RISCV] Add groupid/bitmask for RISC-V extension (#94440) 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.
2024-07-22 14:18:05 +08:00
#include "llvm/ADT/DenseSet.h"
[RISCV] Split code that tablegen needs out of RISCVISAInfo. (#89684) 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.
2024-04-23 15:12:36 -07:00
#include "llvm/Support/RISCVISAUtils.h"
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
#include "llvm/TableGen/Record.h"
llvm-tblgen: Rewrite emitters to use `TableGen::Emitter` Each emitter became self-contained since it has the registration of option. Differential Revision: https://reviews.llvm.org/D144351
2023-02-19 14:30:14 +09:00
#include "llvm/TableGen/TableGenBackend.h"
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
using namespace llvm;
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
static StringRef getExtensionName(const Record *R) {
StringRef Name = R->getValueAsString("Name");
Name.consume_front("experimental-");
return Name;
}
static void printExtensionTable(raw_ostream &OS,
const std::vector<Record *> &Extensions,
bool Experimental) {
OS << "static const RISCVSupportedExtension Supported";
if (Experimental)
OS << "Experimental";
OS << "Extensions[] = {\n";
for (Record *R : Extensions) {
if (R->getValueAsBit("Experimental") != Experimental)
continue;
[NFC][RISCV] use OS.indent() to replace spaces (#102429)
2024-08-08 23:04:39 +08:00
OS.indent(4) << "{\"" << getExtensionName(R) << "\", {"
<< R->getValueAsInt("MajorVersion") << ", "
<< R->getValueAsInt("MinorVersion") << "}},\n";
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
}
OS << "};\n\n";
}
static void emitRISCVExtensions(RecordKeeper &Records, raw_ostream &OS) {
OS << "#ifdef GET_SUPPORTED_EXTENSIONS\n";
OS << "#undef GET_SUPPORTED_EXTENSIONS\n\n";
std::vector<Record *> Extensions =
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
Records.getAllDerivedDefinitionsIfDefined("RISCVExtension");
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
llvm::sort(Extensions, [](const Record *Rec1, const Record *Rec2) {
return getExtensionName(Rec1) < getExtensionName(Rec2);
});
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
if (!Extensions.empty()) {
printExtensionTable(OS, Extensions, /*Experimental=*/false);
printExtensionTable(OS, Extensions, /*Experimental=*/true);
}
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
OS << "#endif // GET_SUPPORTED_EXTENSIONS\n\n";
OS << "#ifdef GET_IMPLIED_EXTENSIONS\n";
OS << "#undef GET_IMPLIED_EXTENSIONS\n\n";
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
if (!Extensions.empty()) {
OS << "\nstatic constexpr ImpliedExtsEntry ImpliedExts[] = {\n";
for (Record *Ext : Extensions) {
auto ImpliesList = Ext->getValueAsListOfDefs("Implies");
if (ImpliesList.empty())
continue;
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
StringRef Name = getExtensionName(Ext);
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
for (auto *ImpliedExt : ImpliesList) {
if (!ImpliedExt->isSubClassOf("RISCVExtension"))
continue;
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
[NFC][RISCV] use OS.indent() to replace spaces (#102429)
2024-08-08 23:04:39 +08:00
OS.indent(4) << "{ {\"" << Name << "\"}, \""
<< getExtensionName(ImpliedExt) << "\"},\n";
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
}
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
}
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
OS << "};\n\n";
}
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
OS << "#endif // GET_IMPLIED_EXTENSIONS\n\n";
}
[RISCV] Generate march string from target features 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
2023-01-16 11:07:34 +08:00
// We can generate march string from target features as what has been described
[RISCV] Replace RISCV -> RISC-V in comments. NFC To be consistent with RISC-V branding guidelines https://riscv.org/about/risc-v-branding-guidelines/ Think we should be using RISC-V where possible. More patches will follow. Reviewed By: asb Differential Revision: https://reviews.llvm.org/D146449
2023-03-27 09:15:53 -07:00
// in RISC-V ISA specification (version 20191213) 'Chapter 27. ISA Extension
[RISCV] Generate march string from target features 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
2023-01-16 11:07:34 +08:00
// Naming Conventions'.
//
// This is almost the same as RISCVFeatures::parseFeatureBits, except that we
// get feature name from feature records instead of feature bits.
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
static void printMArch(raw_ostream &OS, const std::vector<Record *> &Features) {
[RISCV] Move OrderedExtensionMap typedef to RISCVISAUtils.h. NFC
2024-04-26 17:24:41 -07:00
RISCVISAUtils::OrderedExtensionMap Extensions;
[RISCV][TableGen] Generate RISCVTargetParserDef.inc from the new RISCVExtension tblgen information. (#89335) 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.
2024-04-22 20:37:11 -07:00
unsigned XLen = 0;
[RISCV] Generate march string from target features 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
2023-01-16 11:07:34 +08:00
// Convert features to FeatureVector.
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
for (auto *Feature : Features) {
[RISCV][TableGen] Get right experimental extension name 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
2024-04-28 11:16:43 +08:00
StringRef FeatureName = getExtensionName(Feature);
[RISCV][TableGen] Generate RISCVTargetParserDef.inc from the new RISCVExtension tblgen information. (#89335) 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.
2024-04-22 20:37:11 -07:00
if (Feature->isSubClassOf("RISCVExtension")) {
unsigned Major = Feature->getValueAsInt("MajorVersion");
unsigned Minor = Feature->getValueAsInt("MinorVersion");
Extensions[FeatureName.str()] = {Major, Minor};
} else if (FeatureName == "64bit") {
assert(XLen == 0 && "Already determined XLen");
Recommit "[RISCV][TableGen] Move XLen detection into getMArch in RISCVTargetDefEmitter. NFC" Using the correct feature name to detect 64bit this time. Previously, I mistakenly compared the expected record name against a string inside the record.
2023-01-20 12:20:58 -08:00
XLen = 64;
[RISCV][TableGen] Generate RISCVTargetParserDef.inc from the new RISCVExtension tblgen information. (#89335) 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.
2024-04-22 20:37:11 -07:00
} else if (FeatureName == "32bit") {
assert(XLen == 0 && "Already determined XLen");
XLen = 32;
}
[RISCV] Generate march string from target features 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
2023-01-16 11:07:34 +08:00
}
[RISCV][TableGen] Generate RISCVTargetParserDef.inc from the new RISCVExtension tblgen information. (#89335) 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.
2024-04-22 20:37:11 -07:00
assert(XLen != 0 && "Unable to determine XLen");
OS << "rv" << XLen;
[RISCV] Generate march string from target features 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
2023-01-16 11:07:34 +08:00
[RISCV][TableGen] Generate RISCVTargetParserDef.inc from the new RISCVExtension tblgen information. (#89335) 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.
2024-04-22 20:37:11 -07:00
ListSeparator LS("_");
for (auto const &Ext : Extensions)
OS << LS << Ext.first << Ext.second.Major << 'p' << Ext.second.Minor;
[RISCV] Generate march string from target features 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
2023-01-16 11:07:34 +08:00
}
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
[TableGen][RISCV] Add initial support for marking profiles as experimental (#91993) 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.
2024-05-14 05:34:39 +01:00
static void printProfileTable(raw_ostream &OS,
const std::vector<Record *> &Profiles,
bool Experimental) {
OS << "static constexpr RISCVProfile Supported";
if (Experimental)
OS << "Experimental";
OS << "Profiles[] = {\n";
for (const Record *Rec : Profiles) {
if (Rec->getValueAsBit("Experimental") != Experimental)
continue;
[TableGen][RISCV] Strip experimental- prefix in profile names in SupportedExperimentalProfiles This matches what we do for extensions, and saves us having to do it in RISCVISAInfo. This is a minor tweak to what I added in #91993.
2024-05-14 07:19:40 +01:00
StringRef Name = Rec->getValueAsString("Name");
Name.consume_front("experimental-");
OS.indent(4) << "{\"" << Name << "\",\"";
[TableGen][RISCV] Add initial support for marking profiles as experimental (#91993) 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.
2024-05-14 05:34:39 +01:00
printMArch(OS, Rec->getValueAsListOfDefs("Implies"));
OS << "\"},\n";
}
OS << "};\n\n";
}
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
static void emitRISCVProfiles(RecordKeeper &Records, raw_ostream &OS) {
OS << "#ifdef GET_SUPPORTED_PROFILES\n";
OS << "#undef GET_SUPPORTED_PROFILES\n\n";
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
auto Profiles = Records.getAllDerivedDefinitionsIfDefined("RISCVProfile");
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
if (!Profiles.empty()) {
[TableGen][RISCV] Add initial support for marking profiles as experimental (#91993) 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.
2024-05-14 05:34:39 +01:00
printProfileTable(OS, Profiles, /*Experimental=*/false);
bool HasExperimentalProfiles = any_of(Profiles, [&](auto &Rec) {
return Rec->getValueAsBit("Experimental");
});
if (HasExperimentalProfiles)
printProfileTable(OS, Profiles, /*Experimental=*/true);
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
}
OS << "#endif // GET_SUPPORTED_PROFILES\n\n";
}
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
static void emitRISCVProcs(RecordKeeper &RK, raw_ostream &OS) {
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
OS << "#ifndef PROC\n"
[RISCV] Add -m[no-]scalar-strict-align and -m[no-]vector-strict-align. (#95024)
2024-07-14 13:39:17 -07:00
<< "#define PROC(ENUM, NAME, DEFAULT_MARCH, FAST_SCALAR_UNALIGN"
<< ", FAST_VECTOR_UNALIGN)\n"
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
<< "#endif\n\n";
// Iterate on all definition records.
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
for (const Record *Rec :
RK.getAllDerivedDefinitionsIfDefined("RISCVProcessorModel")) {
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
const std::vector<Record *> &Features =
Rec->getValueAsListOfDefs("Features");
bool FastScalarUnalignedAccess = any_of(Features, [&](auto &Feature) {
return Feature->getValueAsString("Name") == "unaligned-scalar-mem";
});
[RISCV][Clang][TargetParser] Support getting feature unaligned-scalar-mem from mcpu. (#71513) 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.
2023-11-08 00:05:16 +08:00
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
bool FastVectorUnalignedAccess = any_of(Features, [&](auto &Feature) {
return Feature->getValueAsString("Name") == "unaligned-vector-mem";
});
[RISCV] Re-separate unaligned scalar and vector memory features in the backend. (#88954) 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.
2024-04-16 15:40:32 -07:00
[RISCV][TableGen] Generate RISCVTargetParserDef.inc from the new RISCVExtension tblgen information. (#89335) 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.
2024-04-22 20:37:11 -07:00
OS << "PROC(" << Rec->getName() << ", {\"" << Rec->getValueAsString("Name")
<< "\"}, {\"";
StringRef MArch = Rec->getValueAsString("DefaultMarch");
// Compute MArch from features if we don't specify it.
if (MArch.empty())
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
printMArch(OS, Features);
[RISCV][TableGen] Generate RISCVTargetParserDef.inc from the new RISCVExtension tblgen information. (#89335) 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.
2024-04-22 20:37:11 -07:00
else
OS << MArch;
[RISCV] Add -m[no-]scalar-strict-align and -m[no-]vector-strict-align. (#95024)
2024-07-14 13:39:17 -07:00
OS << "\"}, " << FastScalarUnalignedAccess << ", "
<< FastVectorUnalignedAccess << ")\n";
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
}
OS << "\n#undef PROC\n";
OS << "\n";
OS << "#ifndef TUNE_PROC\n"
<< "#define TUNE_PROC(ENUM, NAME)\n"
<< "#endif\n\n";
[RISCV][TableGen] Use getAllDerivedDefinitions in RISCVTargetDefEmitter to simplify the code. NFC
2023-01-20 00:20:13 -08:00
for (const Record *Rec :
[TableGen][RISCV] Use getAllDerivedDefinitionsIfDefined in RISCVTargetDefEmitter (#91941) 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.
2024-05-13 17:05:28 +01:00
RK.getAllDerivedDefinitionsIfDefined("RISCVTuneProcessorModel")) {
[RISCV][TableGen] Use getAllDerivedDefinitions in RISCVTargetDefEmitter to simplify the code. NFC
2023-01-20 00:20:13 -08:00
OS << "TUNE_PROC(" << Rec->getName() << ", "
<< "\"" << Rec->getValueAsString("Name") << "\")\n";
[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen. 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.
2023-01-11 10:23:55 +01:00
}
OS << "\n#undef TUNE_PROC\n";
}
llvm-tblgen: Rewrite emitters to use `TableGen::Emitter` Each emitter became self-contained since it has the registration of option. Differential Revision: https://reviews.llvm.org/D144351
2023-02-19 14:30:14 +09:00
[RISCV] Add groupid/bitmask for RISC-V extension (#94440) 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.
2024-07-22 14:18:05 +08:00
static void emitRISCVExtensionBitmask(RecordKeeper &RK, raw_ostream &OS) {
std::vector<Record *> Extensions =
RK.getAllDerivedDefinitionsIfDefined("RISCVExtensionBitmask");
llvm::sort(Extensions, [](const Record *Rec1, const Record *Rec2) {
return getExtensionName(Rec1) < getExtensionName(Rec2);
});
#ifndef NDEBUG
llvm::DenseSet<std::pair<uint64_t, uint64_t>> Seen;
#endif
OS << "#ifdef GET_RISCVExtensionBitmaskTable_IMPL\n";
OS << "static const RISCVExtensionBitmask ExtensionBitmask[]={\n";
for (const Record *Rec : Extensions) {
unsigned GroupIDVal = Rec->getValueAsInt("GroupID");
unsigned BitPosVal = Rec->getValueAsInt("BitPos");
StringRef ExtName = Rec->getValueAsString("Name");
ExtName.consume_front("experimental-");
#ifndef NDEBUG
assert(Seen.insert(std::make_pair(GroupIDVal, BitPosVal)).second &&
"duplicated bitmask");
#endif
[NFC][RISCV] use OS.indent() to replace spaces (#102429)
2024-08-08 23:04:39 +08:00
OS.indent(4) << "{"
<< "\"" << ExtName << "\""
<< ", " << GroupIDVal << ", " << BitPosVal << "ULL"
<< "},\n";
[RISCV] Add groupid/bitmask for RISC-V extension (#94440) 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.
2024-07-22 14:18:05 +08:00
}
OS << "};\n";
OS << "#endif\n";
}
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
static void EmitRISCVTargetDef(RecordKeeper &RK, raw_ostream &OS) {
emitRISCVExtensions(RK, OS);
[RISCV] Generate profiles from RISCVProfiles.td So we can only mantain one place. Reviewers: preames, yetingk, topperc Reviewed By: topperc Pull Request: https://github.com/llvm/llvm-project/pull/90187
2024-04-28 11:52:36 +08:00
emitRISCVProfiles(RK, OS);
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
emitRISCVProcs(RK, OS);
[RISCV] Add groupid/bitmask for RISC-V extension (#94440) 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.
2024-07-22 14:18:05 +08:00
emitRISCVExtensionBitmask(RK, OS);
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
}
llvm-tblgen: Rewrite emitters to use `TableGen::Emitter` Each emitter became self-contained since it has the registration of option. Differential Revision: https://reviews.llvm.org/D144351
2023-02-19 14:30:14 +09:00
static TableGen::Emitter::Opt X("gen-riscv-target-def", EmitRISCVTargetDef,
[RISCV] Generate RISCVISAInfo table from RISCVFeatures.td. (#89955) 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.
2024-04-25 07:07:33 -07:00
"Generate the list of CPUs and extensions for "
"RISC-V");
Reference in New Issue Copy Permalink