[llvm-dev] [RFC] Extension to TableGen's AssemblerPredicates to support combining features with ORs

Simon Cook via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 13 10:13:18 PST 2020


I'd like to propose extending the supported syntax for
AssemblerPredicates to allow sets of SubtargetFeatures to be listed, but
where only one in the list has to be enabled for the predicate to be true.

The condition string which forms a AssemblerPredicate already allows
multiple features to be defined, separated by commas, and this means all
of these features must be present. For example, "Feature1,Feature2"
means that both Feature1 and Feature2 must be enabled in the Subtarget.

I propose extending this using the vertical bar character to mean or, so
eg "Feature1|Feature2" requires at least one of these two be enabled. At
this stage I don't propose allowing ANDs and ORs to combine exist in the
same predicate, this can be revisited in the future if a need is found.

My initial motivation for this relates to the RISC-V backend and it's
upcoming bit manipulation extension. Internally this comprises of
several subextensions, each of which has its own SubtargetFeature. Some
of the instructions in this set require one of two of these target
features to be enabled for the instruction to be valid. Beyond this, I
can see such a feature will be useful elsewhere in the RISC-V backend as
different releases of the ISA would mean some instructions are enabled
or disabled based on one of a set of features being enabled, and such a
feature might be useful to other backends too.

I have implemented a prototype of this extension in
https://reviews.llvm.org/D74338. AssemblerPredicates are used in four
parts of TableGen, three of which only affect TableGen'erated code, and
one is RISC-V specific so these changes are not very intrusive. For
AsmWriterEmitter/MCInstPrinter to work with these changes, I've made
what I think may be a minimally distruptive change, but I'm happy to
hear any alternative ideas on how to express this to the AsmWriter alias
condition code.

I look forward to any ideas and feedback.


More information about the llvm-dev mailing list