[LLVMdev] Simpler types in TableGen isel patterns

[Hal Finkel]

----- Original Message -----
> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
> To: llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu, llvmdev at cs.uiuc.edu
> Sent: Thursday, March 21, 2013 1:26:25 PM
> Subject: [LLVMdev] Simpler types in TableGen isel patterns
> 
> 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.

I think this is a good idea.

Is there a reason why we need the types again in the expansion? Would it be easy to make the syntax like this?

  def : Pat<(and (not i64:$src1), i64:$src2),
            (ANDN64rr     $src1,      $src2)>;

Thanks again,
Hal

> 
> /jakob
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>