This adds a check that all ExtensionWithMArch which are marked as implied features for an architecture are also present in the list of default features. It doesn't make sense to have something mandatory but not on by default. There were a number of existing cases that violated this rule, and some changes to which features are mandatory (indicated by the Implies field). This resulted in a bug where if a feature was marked as `Implies` but was not added to `DefaultExt`, then for `-march=base_arch+nofeat` the Driver would consider `feat` to have never been added and therefore would do nothing to disable it (no `-target-feature -feat` would be added, but the backend would enable the feature by default because of `Implies`). See clang/test/Driver/aarch64-negative-modifiers-for-default-features.c. Note that the processor definitions do not respect the architecture DefaultExts. These apply only when specifying `-march=<some architecture version>`. So when a feature is moved from `Implies` to `DefaultExts` on the Architecture definition, the feature needs to be added to all processor definitions (that are based on that architecture) in order to preserve the existing behaviour. I have checked the TRMs for many cases (see specific commit messages) but in other cases I have just kept the current behaviour and not tried to fix it.
LLVM TableGen
The purpose of TableGen is to generate complex output files based on information from source files that are significantly easier to code than the output files would be, and also easier to maintain and modify over time.
The information is coded in a declarative style involving classes and records, which are then processed by TableGen.
class Hello <string _msg> {
string msg = !strconcat("Hello ", _msg);
}
def HelloWorld: Hello<"world!"> {}
------------- Classes -----------------
class Hello<string Hello:_msg = ?> {
string msg = !strconcat("Hello ", Hello:_msg);
}
------------- Defs -----------------
def HelloWorld { // Hello
string msg = "Hello world!";
}
Try this example on Compiler Explorer.
The internalized records are passed on to various backends, which extract information from a subset of the records and generate one or more output files.
These output files are typically .inc files for C++, but may be any type of file that the backend developer needs.
Resources for learning the language:
- TableGen Overview
- Programmer's reference guide
- Tutorial
- Tools for Learning LLVM TableGen
- Lessons in TableGen (video), slides
- Improving Your TableGen Descriptions (video), slides
Writing TableGen backends:
- TableGen Backend Developer's Guide
- How to write a TableGen backend (video), slides, also available as a notebook.
TableGen in MLIR:
Useful tools: