[PATCH] Allow ParserMatchClass attribute on RegisterClass

[Jakob Stoklund Olesen]

On Mar 28, 2013, at 9:42 AM, Ulrich Weigand <ulrich.weigand at de.ibm.com> wrote:

> 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.

Actually, I think I would prefer the RegisterOperand solution.

As we add new targets, it is becoming clearer that a register class is often insufficient for describing register operands, and I think it is healthy to separate the concepts.

/jakob