[LLVMdev] Simpler types in TableGen isel patterns

[Cameron McInally]

Hey Jakob,

On Thu, Mar 21, 2013 at 2:26 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

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

Shooting from the hip... let's say we had a predicated execution
architecture which had a general integer register class and a mask register
class. Both classes contain i32 as a member and the instructions that
operate on those two register classes are mutually exclusive.

A little example:

Integer AND
=========
iand %i0, %i1

Mask AND
========
mand %m0, %m1

I'm wondering if having a general pattern could cause issues there. A
pattern such as this could match both register classes, leading to a bad
operand in the instruction produced and an assembler error.

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

This shouldn't currently be an issue, but I am trying to look far down the
road. Let's say that predicated execution becomes commonplace down that
road and it's now more beneficial to select patterns on register classes,
rather than types.

To be clear, this is more a thought experiment than a critique. Making your
change won't impact my work and I don't feel strongly for, nor against,
this change.

-Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130321/aee951dc/attachment.html>