-
Notifications
You must be signed in to change notification settings - Fork 14.6k
[MC] Use StringTable to reduce dynamic relocations #144202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,6 +28,7 @@ | |
#include "llvm/Support/raw_ostream.h" | ||
#include "llvm/TableGen/Error.h" | ||
#include "llvm/TableGen/Record.h" | ||
#include "llvm/TableGen/StringToOffsetTable.h" | ||
#include "llvm/TableGen/TableGenBackend.h" | ||
#include "llvm/TargetParser/SubtargetFeature.h" | ||
#include <algorithm> | ||
|
@@ -1456,6 +1457,10 @@ void SubtargetEmitter::emitSchedClassTables(SchedClassTables &SchedTables, | |
} | ||
OS << "}; // " << Target << "ReadAdvanceTable\n"; | ||
|
||
// Pool all SchedClass names in a string table. | ||
StringToOffsetTable StrTab; | ||
unsigned InvalidNameOff = StrTab.GetOrAddStringOffset("InvalidSchedClass"); | ||
|
||
// Emit a SchedClass table for each processor. | ||
for (const auto &[Idx, Proc] : enumerate(SchedModels.procModels())) { | ||
if (!Proc.hasInstrSchedModel()) | ||
|
@@ -1473,14 +1478,15 @@ void SubtargetEmitter::emitSchedClassTables(SchedClassTables &SchedTables, | |
// name and position. | ||
assert(SchedModels.getSchedClass(0).Name == "NoInstrModel" && | ||
"invalid class not first"); | ||
OS << " {DBGFIELD(\"InvalidSchedClass\") " | ||
OS << " {DBGFIELD(" << InvalidNameOff << ") " | ||
<< MCSchedClassDesc::InvalidNumMicroOps | ||
<< ", false, false, false, 0, 0, 0, 0, 0, 0},\n"; | ||
|
||
for (unsigned SCIdx = 1, SCEnd = SCTab.size(); SCIdx != SCEnd; ++SCIdx) { | ||
MCSchedClassDesc &MCDesc = SCTab[SCIdx]; | ||
const CodeGenSchedClass &SchedClass = SchedModels.getSchedClass(SCIdx); | ||
OS << " {DBGFIELD(\"" << SchedClass.Name << "\") "; | ||
unsigned NameOff = StrTab.GetOrAddStringOffset(SchedClass.Name); | ||
OS << " {DBGFIELD(/*" << SchedClass.Name << "*/ " << NameOff << ") "; | ||
if (SchedClass.Name.size() < 18) | ||
OS.indent(18 - SchedClass.Name.size()); | ||
OS << MCDesc.NumMicroOps << ", " << (MCDesc.BeginGroup ? "true" : "false") | ||
|
@@ -1495,6 +1501,8 @@ void SubtargetEmitter::emitSchedClassTables(SchedClassTables &SchedTables, | |
} | ||
OS << "}; // " << Proc.ModelName << "SchedClasses\n"; | ||
} | ||
|
||
StrTab.EmitStringTableDef(OS, Target + "SchedClassNames"); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we move this behind the NDEBUG check as well, or do we just rely on it being DCEd? (Do we need to suppress a warning about an unused static in release builds possibly?) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don’t think that DCE would occur in the dynamic build. This is an exposed interface, and unless it was marked as infused or static, the linker cannot know it it’s safe to remove. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I didn't want the tablegen output to depend on the assertion mode. For most common builds, this doesn't matter, because tablgen is built using the host configuration, but there are some more advanced build configurations where tablegen is separate, and I wouldn't want to have to figure out how to plumb that configuration option through to trigger a tablegen re-run. My intention is that we just rely on DCE, since it's trivially dead in the TU. I'm not getting a warning locally in NDEBUG builds, but I'm not sure why, because godbolt code samples show that we should warn in cases like this: That investigation will continue. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Coming back around to this, it appears that we suppress unused const variable warnings when the variable isn't in the main source file. My test not-minimal test sources looked like this:
And if you put the unused variable in in place of the include, you get the expected warning:
So, I think this is all WAI. The suppression makes sense, it's probably intended to avoid warning about Any other blocking concerns, or is this good to go? |
||
} | ||
|
||
void SubtargetEmitter::emitProcessorModels(raw_ostream &OS) { | ||
|
@@ -1548,6 +1556,8 @@ void SubtargetEmitter::emitProcessorModels(raw_ostream &OS) { | |
else | ||
OS << " nullptr, nullptr, 0, 0," | ||
<< " // No instruction-level machine model.\n"; | ||
OS << " DBGVAL_OR_NULLPTR(&" << Target | ||
<< "SchedClassNames), // SchedClassNames\n"; | ||
if (PM.hasItineraries()) | ||
OS << " " << PM.ItinsDef->getName() << ",\n"; | ||
else | ||
|
@@ -1569,8 +1579,10 @@ void SubtargetEmitter::emitSchedModel(raw_ostream &OS) { | |
<< "#endif\n" | ||
<< "#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)\n" | ||
<< "#define DBGFIELD(x) x,\n" | ||
<< "#define DBGVAL_OR_NULLPTR(x) x\n" | ||
<< "#else\n" | ||
<< "#define DBGFIELD(x)\n" | ||
<< "#define DBGVAL_OR_NULLPTR(x) nullptr\n" | ||
<< "#endif\n"; | ||
|
||
if (SchedModels.hasItineraries()) { | ||
|
@@ -1588,10 +1600,11 @@ void SubtargetEmitter::emitSchedModel(raw_ostream &OS) { | |
} | ||
emitSchedClassTables(SchedTables, OS); | ||
|
||
OS << "\n#undef DBGFIELD\n"; | ||
|
||
// Emit the processor machine model | ||
emitProcessorModels(OS); | ||
|
||
OS << "\n#undef DBGFIELD\n"; | ||
OS << "\n#undef DBGVAL_OR_NULLPTR\n"; | ||
} | ||
|
||
static void emitPredicateProlog(const RecordKeeper &Records, raw_ostream &OS) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the field is declared conditionally here, but then initialized unconditionally both via TableGen and in the test file?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a concern - hopefully a -Asserts build would just fail and catch this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, that was an oversight. In the end, there are very few MCSchedModel instances, so having an empty field isn't that important. Fewer ifdefs seems like the better tradeoff.