<div dir="ltr">This sounds great!  I've been bitten in the past by trying to use a single class for multiple types.<div><br></div><div style>Would it make sense to extend this to all DAG patterns?  If I have an instruction def:</div>
<div style><br></div><div style><font face="courier new, monospace">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))))]>;</font></div>
<div style><br></div><div style>would I now be able to write:</div><div style><br></div><div style><font face="courier new, monospace">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))))]>;</font><br>
</div><div style><br></div><div style>?</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 3:00 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Jakob Stoklund Olesen" <<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>><br>
> To: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>, <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>, <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>, <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>

> Sent: Thursday, March 21, 2013 1:26:25 PM<br>
> Subject: [LLVMdev] Simpler types in TableGen isel patterns<br>
><br>
> Currently, instruction selection patterns are defined like this:<br>
><br>
>   def : Pat<(and (not GR32:$src1), GR32:$src2),<br>
>             (ANDN32rr GR32:$src1, GR32:$src2)>;<br>
>   def : Pat<(and (not GR64:$src1), GR64:$src2),<br>
>             (ANDN64rr GR64:$src1, GR64:$src2)>;<br>
><br>
> TableGen infers the types of $src1 and $src2 from the specified<br>
> register classes, and that is the only purpose of the register<br>
> classes in a pattern like that. SelectionDAG doesn't really<br>
> understand register classes, it only uses types.<br>
><br>
> If I try to constrain the register class in a pattern, like this:<br>
><br>
>   def : Pat<(and (not GR32_ABCD:$src1), GR32_ABCD:$src2),<br>
>             (ANDN32rr GR32_ABCD:$src1, GR32_ABCD:$src2)>;<br>
><br>
> I get completely ignored. SelectionDAG's InstrEmitter will still use<br>
> the GR32 register class that was assigned to the i32 type.<br>
><br>
> When using register classes as proxies for types, it also becomes<br>
> very difficult to support more than one legal type in a register<br>
> class. If I were to entertain the heretic notion that an f32 might<br>
> fit in a 32-bit register:<br>
><br>
>   def GR32 : RegisterClass<"X86", [i32, f32], 32, ...<br>
><br>
> TableGen explodes with a thousand type inference errors.<br>
><br>
><br>
> I think in most cases it would be much simpler and safer to specify<br>
> pattern types directly:<br>
><br>
>   def : Pat<(and (not i32:$src1), i32:$src2),<br>
>             (ANDN32rr i32:$src1,  i32:$src2)>;<br>
>   def : Pat<(and (not i64:$src1), i64:$src2),<br>
>             (ANDN64rr i64:$src1,  i64:$src2)>;<br>
><br>
> This doesn't lose any type checking because the register classes of<br>
> the instructions in the output pattern are still checked. It avoids<br>
> the problem where type inference makes it impractical to add types<br>
> to a register class to model instruction set extensions, and it<br>
> makes it clear that patterns operate on types, not register classes.<br>
><br>
> I'll add support for this syntax unless someone can think of a reason<br>
> I shouldn't. The notation using register classes gets to stay, I'm<br>
> not removing it.<br>
<br>
</div></div>I think this is a good idea.<br>
<br>
Is there a reason why we need the types again in the expansion? Would it be easy to make the syntax like this?<br>
<div class="im"><br>
  def : Pat<(and (not i64:$src1), i64:$src2),<br>
</div>            (ANDN64rr     $src1,      $src2)>;<br>
<br>
Thanks again,<br>
Hal<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> /jakob<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>