Add a convenience wrapper struct for the `bit_value_t` enum type to host various constructors, query, and printing support. Also refactor related code in several places. In `getBitsField`, use `llvm::append_range` and `SmallVector::append()` and eliminate manual loops. Eliminate `emitNameWithID` and instead use the `operator <<` that does the same thing as this function. Have `BitValue::getValue()` (replacement for `Value`) return std::optional<> instead of -1 for unset bits. Terminate with a fatal error when a decoding conflict is encountered.
Work towards separating the ABI existence of libcalls vs. the lowering selection. Set libcall selection through enums, rather than through raw string names.
Replace RuntimeLibcalls.def with a tablegenerated version. This is in preparation for splitting RuntimeLibcalls into two components. For now match the existing functionality.
Dynamic relocations are expensive on ELF/Linux platforms because they are applied in userspace on process startup. Therefore, it is worth optimizing them to make PIE and PIC dylib builds faster. In +asserts builds (non-NDEBUG), nikic identified these schedule class name string pointers as the leading source of dynamic relocations. [1] This change uses llvm::StringTable and the StringToOffsetTable TableGen helper to turn the string pointers into 32-bit offsets into a separate character array. The number of dynamic relocations is reduced by ~60%: ❯ llvm-readelf --dyn-relocations lib/libLLVM.so | wc -l 381376 # before 155156 # after The test suite time is modestly affected, but I'm running on a shared noisy workstation VM with a ton of cores: https://gist.github.com/rnk/f38882c2fe2e63d0eb58b8fffeab69de Testing Time: 100.88s # before Testing Time: 78.50s. # after Testing Time: 96.25s. # before again I haven't used any fancy hyperfine/denoising tools, but I think the result is clearly visible and we should ship it. [1] https://gist.github.com/nikic/554f0a544ca15d5219788f1030f78c5a
Add option `use-fn-table-in-decode-to-mcinst` to use a table of function pointers instead of a switch case in the generated `decodeToMCInst` function. When the number of switch cases in this function is large, the generated code takes a long time to compile in release builds. Using a table of function pointers instead improves the compile time significantly (~3x speedup in compiling the code in a downstream target). This option will allow targets to opt into this mode if they desire for better build times. Tested with `check-llvm-mc` with the option enabled by default.
This patch adds an even more aggressive short-circuit on `!and` and `!or` that completely avoids the evaluation of RHS operand until short circuiting decisions are made.
Solves unused variable error in generated Global ISel code due to changes from #140935
Previously PatLeafs could not be imported, causing the following warnings to be emitted when running tblgen with `-warn-on-skipped-patterns:` ``` /work/clean/llvm/lib/Target/AArch64/AArch64InstrInfo.td:2631:1: warning: Skipped pattern: Src pattern child has unsupported predicate def : Pat<(i64 (mul top32Zero:$Rn, top32Zero:$Rm)), ^ ``` These changes allow the patterns to now be imported successfully.
In "get<lang>DirectiveName(Kind, Version)", return the spelling that
corresponds to Version, and in "get<lang>DirectiveKindAndVersions(Name)"
return the pair {Kind, VersionRange}, where VersionRange contains the
minimum and the maximum versions that allow "Name" as a spelling. This
applies to clauses as well. In general it applies to classes that have
spellings (defined via TableGen class "Spelling").
Given a Kind and a Version, getting the corresponding spelling requires
a runtime search (which can fail in a general case). To avoid generating
the search function inline, a small additional component of
llvm/Frontent was added: LLVMFrontendDirective. The corresponding header
file also defines C++ classes "Spelling" and "VersionRange", which are
used in TableGen/DirectiveEmitter as well.
For background information see
https://discourse.llvm.org/t/rfc-alternative-spellings-of-openmp-directives/85507
Print DecodeIdx associated with Decode MCD ops in the generated decoder tables. This can help in debugging decode failures by first mapping the Op -> DecodeIdx and then inspecting the code in `decodeToMCInst` associated with that DecodeIdx.