[PATCH] Allow ParserMatchClass attribute on RegisterClass

[Jim Grosbach]

On Mar 28, 2013, at 10:03 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

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

Yes. The RegisterOperand class is designed for exactly this sort of separation of concerns.

-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130328/5c08d189/attachment.html>