[LLVMdev] Simpler types in TableGen isel patterns

[Jakob Stoklund Olesen]

On Mar 21, 2013, at 1:39 PM, Chris Lattner <clattner at apple.com> wrote:

> On Mar 21, 2013, at 11:26 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>> I think in most cases it would be much simpler and safer to specify pattern types directly:
>> 
>> def : Pat<(and (not i32:$src1), i32:$src2),
>>           (ANDN32rr i32:$src1,  i32:$src2)>;
>> def : Pat<(and (not i64:$src1), i64:$src2),
>>           (ANDN64rr i64:$src1,  i64:$src2)>;
>> 
>> This doesn't lose any type checking because the register classes of the instructions in the output pattern are still checked. It avoids the problem where type inference makes it impractical to add types to a register class to model instruction set extensions, and it makes it clear that patterns operate on types, not register classes.
> 
> This makes a huge amount of sense to me.  Besides your motivating problem, writing an isel pattern that matches things in terms of register classes doesn't make *any* sense: the input graph has type labels that are MVTs.

Exactly. The register classes are misleading.

> If you want to get *really* crazy, the ideal type system for dag nodes would be to allow either an EVT or a register class: after isel (and after some custom dag combines) the types of nodes should be register classes, since they are more specific than an MVT (or EVT).

Yes, that is also the direction I would like to go.

We have started taking baby steps in this direction with the 'untyped' MVT. The register class for an untyped DAG edge is determined by the defining instruction alone. TLI.getRegClassFor() is not consulted.

To clarify how register classes are computed today:

- For a typed edge, the RC is computed as the intersection of TLI.getRegClassFor(type) and the register constraints imposed by all the virtual register's uses and defs.

- For an untyped edge, the RC is the intersection of the def constraint and all the uses' constraints.

Thanks,
/jakob