[LLVMdev] Simpler types in TableGen isel patterns

[Justin Holewinski]

This sounds great!  I've been bitten in the past by trying to use a single
class for multiple types.

Would it make sense to extend this to all DAG patterns?  If I have an
instruction def:

def ANDN64 : MyInst<(outs Reg64:$d), (ins Reg64:$a, Reg64:$b), "and.64 $d,
$a, $b", [(set Reg64:$d, (and (not (Reg64:$a, Reg64:$b))))]>;

would I now be able to write:

def ANDN64 : MyInst<(outs Reg64:$d), (ins Reg64:$a, Reg64:$b), "and.64 $d,
$a, $b", [(set i64:$d, (and (not (i64:$a, i64:$b))))]>;

?



On Thu, Mar 21, 2013 at 3:00 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- 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
> >
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130321/4b9a5913/attachment.html>