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

Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Sat Feb 15 13:19:41 PST 2020

Hi Simon,

On Thu, Feb 13, 2020 at 7:13 PM Simon Cook via llvm-dev <llvm-dev at lists.llvm.org> wrote:

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.

This seems like an eminently reasonable feature to want to have.

I'm only worried that we're moving too far along the path of having DSLs inside DSLs. I suppose the first step was already made when adding comma-separated lists there, but perhaps we can still turn back and using something more TableGen-y instead?

For example, rather than "AsmCond1,AsmCond2" or "AsmCond1|AsmCond2", could we perhaps allow dag expressions that look like (and AsmCond1 AsmCond2) and (or AsmCond1 AsmCond2), respectively?

Cheers, Nicolai

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. Thanks, Simon

LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

More information about the llvm-dev mailing list