A TableGen instruction record usually contains a DAG pattern that will
describe the SelectionDAG operation that can be implemented by this
instruction. However, there will be cases where several different DAG
patterns can all be implemented by the same instruction. The way to
represent this today is to write additional patterns in the Pattern
(or usually Pat) class that map those extra DAG patterns to the
instruction. This usually also works fine.
However, I've noticed cases where the current setup seems to require
quite a bit of extra (and duplicated) text in the target .td files.
For example, in the SystemZ back-end, there are quite a number of
instructions that can implement an "add-with-overflow" operation.
The same instructions also need to be used to implement just plain
addition (simply ignoring the extra overflow output). The current
solution requires creating extra Pat pattern for every instruction,
duplicating the information about which particular add operands
map best to which particular instruction.
Similarly, when working on my current proposal to support strict
floating-point operations in the back-end, it seems that this will
require (at least) two patterns for each floating-point instruction:
one that matches the regular FP operation, and one that matches the
strict FP operation -- the latter must be distinct at the DAG level
since it carries a chain.
It seems to me that it might be useful to have TableGen implicity
generate multiple DAG matcher patterns for a single instruction,
without having to explicitly spell those out in the .td files.
Looking at CodeGenDAGPatterns.cpp, I see some precedents for this
idea: there is already "ExpandHwModeBasedTypes", which implicitly
generates multiple patterns for different HW types, and there is
"GenerateVariants", which implictly generates multiple patterns
based on arithmetic combinations of commutative / associative
operations.
Along those lines, I'd like to propose a new feature that allows a
back-end implementer to concisely write instruction patterns that
match multiple "alternative" DAG patterns and will be implicitly
expanded into regular DAG matchers by TableGen. As an example,
this patch uses the feature in the SystemZ back-end to eliminate
all the duplicated Pat patterns for add/sub instructions mentioned
above. In their place, I can now simply define an alternative:
def z_sadd : PatFrag<(ops node:$src1, node:$src2),
(alternative (z_saddo node:$src1, node:$src2),
(add node:$src1, node:$src2))>;and then write all "addition" instructions to match the z_sadd
operation. This will then get expanded into two DAG matchers
for each of those instructions, one matching z_saddo (which maps
the add-with-overflow operation) and one matching a regular add.
The implementation is mostly straightforward; the actual generation
of duplicated patterns is done by a new routine EnumerateAlternatives,
implemented along the lines of ExpandHwModeBasedTypes and GenerateVariants.
There's one not quite obvious change required: GetNumNodeResults now
needs to take a DagInit operand instead of an Operator, since for
"alternative" records we need to iterate across the DAG children
to determine the number of results of all alternatives. Since the
caller of GetNumNodeResults doesn't have a DagInit, but at this
point the Operator is actually always an instruction, this now
calls an outlined routine GetNumInstructionResults.
Note that "alternative" nodes are completely eliminated by
EnumerateAlternatives, so there are no "down-stream" code changes
required beyond this point at all. The generation of the
SelectionDAG matchers works unchanged as-is (and similarly there
are no changes required to GlobalISel).