llvm dev - Apr 2021 - Tablegen: Instruction 'Predicates' vs Pattern 'Predicates'

Starting off with the question: Should Pattern objects (standalone match rules
that are not part of an Instruction definition) inherit the Predicates of the
Instruction(s?) referenced in ResultInstrs? Is there a counter-example where a
target would want to match and select an instruction, even though the
instruction is illegal in the given configuration?

I found a somewhat relevant email from back in 2019, "Please expose
predicates to MachineVerifier" that has the quote: "...currently, at
least for some targets, we use Requires predicates on instructions which are
legal, but we don't want the TableGen'ed isel to select for some
reason." This seems like the inverse of my question, and logically makes
sense. However, selecting an instruction which isn't legal does not make
logical sense to me.

My experience which prompted the question follows
-----

Our downstream target automatically generates Instruction definitions as a sort
of ISA database for our LLVM target. We then utilize this database when defining
the instruction selection automaton's rules.

In database (automatically generated):

def AddInstr : Instruction<...> {
                // Encoding, operands, implicit defs/uses, etc.
                ...
                // No ISel code
                let Pattern = [];
}

In backend definitions (manually written):

// Match LLVM IR add of i32s into AddInstr
def : Pat<(add i32:$src1, i32:$src2), (AddInstr i32:$src1, i32:$src2)>;

Now consider the introduction of a subtarget that doesn't include AddInstr
as part of the ISA. It was fairly easy to generate the following:

def AddInstr : Instruction<...>, Requires<[IsNotSubtarget]> {
...
}

This resulted in useful code from the assembly parser, disassembler, and
MCCodeEmitter for verification. However, it did not affect the instruction
selector in any way. ISel still matched the above Pattern without diagnostics,
and an inspection of the tablegen'd selection DAG did not contain any
commands to check a predicate. What confuses me is that there is a
'Predicates' field for both Pattern objects as well as for the
instruction that patterns reference, but they do not interact at all.

In the TableGen backend CodeGenDAGPatterns, I see that the backend finds
instructions in the destination pattern:
https://github.com/llvm/llvm-project/blob/44ce487bfe8badc3e3718e7cc81c289540e6725d/llvm/utils/TableGen/CodeGenDAGPatterns.cpp#L3993

So couldn't this model be used to append referenced Instruction Predicates
onto the Pattern object? This avoids duplication and, at least in our case,
allows the responsibility of getting Predicates right to be placed on the
automatic generation, rather than a human developer.

J.B Nagurne
Code Generation
Texas Instruments
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210409/8b8db417/attachment.html>