[PATCH] Allow ParserMatchClass attribute on RegisterClass

Ulrich Weigand Ulrich.Weigand at de.ibm.com
Thu Mar 28 09:42:29 PDT 2013


Jakob,

this patch is the last piece of common TableGen changes I need to support
the PowerPC asm parser.

The problem intended to be solved by this patch is a peculiarity of the
PowerPC assembler format.  The general "flow" of the assembler parser on
other platforms is that common code will first attempt to classify all
instruction operands into categories like "Register of class X",
"Immediate", or "Memory address", and *then* go into the instruction table
using the opcode and list of operand types to select the matching pattern.
This approach assumes that you *can* classify operands by just looking at
them in isolation.  Unfortunately this is not true on PowerPC, since
registers are specified in assembler source simply by their numbers, making
them indistinguishable from small immediates.  For example, the "3" in "add
1, 2, 3" refers to a register while the "3" in "addi 1, 2, 3" refers to the
immediate value.  This means that basically the whole generic mechanism of
classifying operands into register classes does not work, and we need to
instead define back-end matchers for all the register classes.

This would be possible without common code changes by using RegisterOperand
classes to specify a ParserMatchClass -- but this means that every instance
of a register class in the .td files must be replaced by the corresponding
RegisterOperand class, which seems a bit unnecessary to me, and may cause
future maintainability hassles.  I'd propose to instead allow specifying a
ParserMatchClass directly on the RegisterClass itself, which can be done by
a minor TableGen change as implemented by this patch.

Does this look reasonable?

Thanks,
Ulrich

(See attached file: diff-llvm-tblgen-regclass)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-llvm-tblgen-regclass
Type: application/octet-stream
Size: 2588 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130328/629f76e6/attachment.obj>


More information about the llvm-commits mailing list