<div dir="ltr"><div>Can someone please tell me where in the ISEL process is the heuristic for assigning reg classes?</div><div><br></div><div>Thank you.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 7:00 PM, Ryan Taylor <span dir="ltr"><<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Ryan Taylor</b> <span dir="ltr"><<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>></span><br>Date: Mon, Aug 17, 2015 at 6:59 PM<br>Subject: Re: [LLVMdev] TableGen Register Class not matching for MI in 3.6<br>To: Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>><br>Cc: "<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>" <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br><br><br><div dir="ltr"><div>The isel logs are exactly the same, nothing changed, it's matching the same instructions just the reg classes are different.</div><div><br></div><div>Where in the SelectionDAG is the code that adds an extra MI COPY? I'll have to set a breakpoint and debug backwards from there to see what's going on. It's only happening with the GPRRegs class, for example if I use another reg class instead along with the base regs than it matches the base reg just fine, it's like GPR is overriding any other reg class matching.</div><div><br></div><div>Thanks.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 31, 2015 at 1:21 PM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Jul 31, 2015, at 10:14 AM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>Quentin,</div><div><br></div><div> It's in the instruction selection, sorry I forgot to mention that. The Vreg class is GPR and an extra COPY is generated to copy from the GPR to the Base Reg, even though my 'mov' instruction has Base in the Register class list.</div></div></div></blockquote><div><br></div></span><div>Then, I suggest you use -debug-only=isel to check what changed in your selection instruction process. I do not see off-hand what could have caused.</div><div><br></div><div>Sorry for not being more helpful here.</div><span><font color="#888888"><div><br></div><div>Q.</div></font></span><div><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 31, 2015 at 12:50 PM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ryan,<br>
<br>
Could you check where those moves come from?<br>
<br>
In particular, is this the product of the instruction selection process?<br>
<br>
You use -print-machineinstrs to see when it is inserted.<br>
<br>
Thanks,<br>
-Quentin<br>
<div><div><br>
> On Jul 30, 2015, at 2:02 PM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>> wrote:<br>
><br>
> In LLVM 3.6,<br>
><br>
>  We have an instruction that uses a register class that is defined of several different reg classes. In 3.4 this works fine but in 3.6 this is broken.<br>
><br>
> For example, I have a mov instruction. mov can be executed between different register types (ie gpr, index, base, etc..)<br>
><br>
> In 3.4, we would get something like this:<br>
><br>
> mov @a, %b1 // moving this immediate to a base register, which is what we want<br>
><br>
> In 3.6, we now get this:<br>
><br>
> mov @a, %r0  // r0 = gpr<br>
> mov %r0, %b1 // b1 = base reg<br>
><br>
> The register class looks like this:<br>
><br>
> def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, BaseRegs)>;<br>
><br>
> I have absolutely no idea why this is not matching any longer?<br>
><br>
> The fix here is to define an MI with explicit single register class (ie it only allows PTRRegs as the destination).<br>
><br>
> This must be an issue with something else and not the tablegen but if that was the case I'm not sure. Anyway help would be great, what should I be looking at here?<br>
><br>
> Thanks.<br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank" rel="noreferrer">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" rel="noreferrer">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</blockquote></div><br></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div>
</div></div></div><br></div>
</blockquote></div><br></div>