[llvm] r177829 - Use direct types in Sparc def : Pat patterns.

[Jakob Stoklund Olesen]

On Mar 23, 2013, at 6:36 PM, Chris Lattner <clattner at apple.com> wrote:

>> -def : Pat<(ctpop IntRegs:$src),
>> -          (POPCrr (SLLri IntRegs:$src, 0))>;
>> +def : Pat<(ctpop i32:$src),
>> +          (POPCrr (SLLri i32:$src, 0))>;

> Does this patch make sense?  SLLri does require its input to be a
> GPR, not just anything that is i32.

Right, but the register class in the pattern was never used to enforce that. It was only used to provide a type.

The register class constraint on SLLri operands comes from the ins and outs lists in the instruction definition:

multiclass F3_12<string OpcStr, bits<6> Op3Val, SDNode OpNode> {
  def rr  : F3_1<2, Op3Val, 
                 (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
                 !strconcat(OpcStr, " $b, $c, $dst"),
                 [(set i32:$dst, (OpNode i32:$b, i32:$c))]>;
  def ri  : F3_2<2, Op3Val,
                 (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c),
                 !strconcat(OpcStr, " $b, $c, $dst"),
                 [(set i32:$dst, (OpNode i32:$b, (i32 simm13:$c)))]>;
}

Suppose there were an OtherIntRegs register class that could also hold an i32. If the pattern was given as:

  def : Pat<(ctpop OtherIntRegs:$src),
            (POPCrr (SLLri OtherIntRegs:$src, 0))>;

We would still try to use an IntRegs register class, because that is what TLI.getClassFor(i32) returns.

I think it is misleading to provide register classes in patterns when they are simply ignored except for type information.

/jakob