<div dir="ltr"><br><div class="gmail_extra"><br><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></blockquote><div><br></div><div style>How come the Hexagone backend is able to get away with that then?</div><div style><br></div><div style><div>def IntRegs : RegisterClass<"Hexagon", [i32,f32], 32,</div>
<div><br></div></div><div> </div></div><br></div></div>