<div>Hey Jakob,<br><div><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 2:26 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank">stoklund@2pi.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 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.<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 the GR32 register class that was assigned to the i32 type.<br>
<br>
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:<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 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 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.<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>A little example:</div><div><br></div><div>Integer AND</div><div>=========</div><div>iand %i0, %i1</div><div><br></div><div>Mask AND</div><div>========</div><div>mand %m0, %m1</div><div><br></div><div>
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.</div><div><br>
</div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"> def : Pat<(and (not i32:$src1), i32:$src2),</span><br style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"> (ANDN32rr i32:$src1, i32:$src2)>;</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br>
</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">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. </span></div>
<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></span></div><div><font color="#222222" face="arial, sans-serif">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. </font></div>
<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">-Cameron</span></div>
</div></div></div>