[LLVMdev] Simpler types in TableGen isel patterns

[Jakob Stoklund Olesen]

Currently, instruction selection patterns are defined like this:

  def : Pat<(and (not GR32:$src1), GR32:$src2),
            (ANDN32rr GR32:$src1, GR32:$src2)>;
  def : Pat<(and (not GR64:$src1), GR64:$src2),
            (ANDN64rr GR64:$src1, GR64:$src2)>;
 
TableGen infers the types of $src1 and $src2 from the specified register classes, and that is the only purpose of the register classes in a pattern like that. SelectionDAG doesn't really understand register classes, it only uses types.

If I try to constrain the register class in a pattern, like this:

  def : Pat<(and (not GR32_ABCD:$src1), GR32_ABCD:$src2),
            (ANDN32rr GR32_ABCD:$src1, GR32_ABCD:$src2)>;

I get completely ignored. SelectionDAG's InstrEmitter will still use the GR32 register class that was assigned to the i32 type.

When using register classes as proxies for types, it also becomes very difficult to support more than one legal type in a register class. If I were to entertain the heretic notion that an f32 might fit in a 32-bit register:

  def GR32 : RegisterClass<"X86", [i32, f32], 32, ...

TableGen explodes with a thousand type inference errors.


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.

I'll add support for this syntax unless someone can think of a reason I shouldn't. The notation using register classes gets to stay, I'm not removing it.

/jakob