<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 22, 2015, at 9:10 AM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" class="">ryta1203@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">One last question regarding this please.</div><div class=""><br class=""></div><div class="">Why aren't we simply changing the register class in AddRegisterOperand instead of building a new COPY? I admit I haven't thought this out but for my test cases so far this works just fine and reduces the number of ASM mov instructions that are being produced.</div><div class=""><br class=""></div><div class="">For example, instead of BuildMI(..., TII->get(TargetOpcode::COPY), NewVReg).addReg(VReg), use something like MRI->setRegClass(VReg, MRI->getRegClass(NewVReg)) ?</div></div></div></blockquote><div><br class=""></div><div>The problem is that the old register class and the new one may not intersect. I do not know exactly what makes us create a new vreg w.r.t., but probably if the class is not identical we create one. You can try to use contraintsRegClass to get the intersection.</div><div><br class=""></div><div>Q.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">What is the reasoning behind adding the extra instruction instead of changing the reg class? </div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Aug 19, 2015 at 2:04 PM, Ryan Taylor <span dir="ltr" class=""><<a href="mailto:ryta1203@gmail.com" target="_blank" class="">ryta1203@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time).</div><div class=""><br class=""></div><div class="">Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a superset reg class that actually matched the correct reg usage (which it sort of does in AddRegisterOperand when it adds the extra COPY.... not sure why it does this instead of just checking the original MI and seeing if the reg class needed is in the list and then just changing the vreg reg class for the original MI, that seems like a better solution?) It's like it's actually picking some reg class first and then trying to fix it's error by adding MORE instructions instead of finding the right reg class the first time.</div><div class=""><br class=""></div><div class="">Thanks.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Aug 19, 2015 at 1:32 PM, Quentin Colombet <span dir="ltr" class=""><<a href="mailto:qcolombet@apple.com" target="_blank" class="">qcolombet@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Aug 19, 2015, at 9:42 AM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank" class="">ryta1203@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">It seems the problem arises from using multiple reg classes for one MI in the td file, I guess.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Probably, that does not sound something used widely :).</div><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> I'm not sure it takes first available, if I swap the reg classes in the list it does not change and if I replace the GPR reg class with something different than it picks the base reg class fine, potentially it is using the reg class with most available? idk.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">My guess is it would take the register class that come first in the register class IDs (not the list on the instruction itself), but I am just guessing.</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I just need to create MIs for every possible case I guess. </div><div class="">Thanks for the help! :)</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Aug 19, 2015 at 12:04 PM, Quentin Colombet <span dir="ltr" class=""><<a href="mailto:qcolombet@apple.com" target="_blank" class="">qcolombet@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Hi Ryan,</div><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Aug 19, 2015, at 6:35 AM, Ryan Taylor via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">Essentially it doesn't appear that the reg class assignment is based on uses and is instead inserting an extra COPY for this. Is this accurate? If so, why?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">We match the instructions bottom-up and I believe that copy are automatically inserted when the register classes do not match.</div><div class="">That seems strange to me that the isel logs are exactly the same but still you are seeing a different result of instruction selection.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">In this above example, I'm getting an extra "mov %r0, $b1" (this is an MI::COPY) even though "mov @a, %b1" (this is an MI::MOV) is entirely acceptable since both GPRRegs and BaseRegs are in the reg class list..</div><div class=""><br class=""></div><div class="">If the heuristic is simply picking the first available reg class or the reg class with the most available, for example, instead of picking the reg class based on uses, I will have to change this heuristic to reduce code bloat, or we'll have to add backend passes to reduce the code bloat.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I think the current approach is rather simple and we just match the type for the first available reg class (assuming your selection dag patterns are not choosing something different). There are not per say passes to reduce this "code bloat” since we never encounter this problem in practice. The peephole optimizer has some logic to avoid this move and CodeGenPrepare also does a few transformation to avoid some of that.</div><div class=""><br class=""></div><div class="">Anyhow, I’d say debug the isel process (probably the InstrEmitter part) to see where the problem arise.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">-Quentin</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Thanks.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Aug 17, 2015 at 7:00 PM, Ryan Taylor <span dir="ltr" class=""><<a href="mailto:ryta1203@gmail.com" target="_blank" class="">ryta1203@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><br class=""><div class="gmail_quote">---------- Forwarded message ----------<br class="">From: <b class="gmail_sendername">Ryan Taylor</b> <span dir="ltr" class=""><<a href="mailto:ryta1203@gmail.com" target="_blank" class="">ryta1203@gmail.com</a>></span><br class="">Date: Mon, Aug 17, 2015 at 6:59 PM<br class="">Subject: Re: [LLVMdev] TableGen Register Class not matching for MI in 3.6<br class="">To: Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank" class="">qcolombet@apple.com</a>><br class="">Cc: "<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank" class="">llvmdev@cs.uiuc.edu</a>" <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank" class="">llvmdev@cs.uiuc.edu</a>><br class=""><br class=""><br class=""><div dir="ltr" class=""><div class="">The isel logs are exactly the same, nothing changed, it's matching the same instructions just the reg classes are different.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Thanks.</div></div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jul 31, 2015 at 1:21 PM, Quentin Colombet <span dir="ltr" class=""><<a href="mailto:qcolombet@apple.com" target="_blank" class="">qcolombet@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 31, 2015, at 10:14 AM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank" class="">ryta1203@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">Quentin,</div><div class=""><br class=""></div><div class=""> 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 class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class="">Sorry for not being more helpful here.</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Q.</div></font></span><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jul 31, 2015 at 12:50 PM, Quentin Colombet <span dir="ltr" class=""><<a href="mailto:qcolombet@apple.com" target="_blank" class="">qcolombet@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ryan,<br class="">
<br class="">
Could you check where those moves come from?<br class="">
<br class="">
In particular, is this the product of the instruction selection process?<br class="">
<br class="">
You use -print-machineinstrs to see when it is inserted.<br class="">
<br class="">
Thanks,<br class="">
-Quentin<br class="">
<div class=""><div class=""><br class="">
> On Jul 30, 2015, at 2:02 PM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank" class="">ryta1203@gmail.com</a>> wrote:<br class="">
><br class="">
> In LLVM 3.6,<br class="">
><br class="">
>  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 class="">
><br class="">
> For example, I have a mov instruction. mov can be executed between different register types (ie gpr, index, base, etc..)<br class="">
><br class="">
> In 3.4, we would get something like this:<br class="">
><br class="">
> mov @a, %b1 // moving this immediate to a base register, which is what we want<br class="">
><br class="">
> In 3.6, we now get this:<br class="">
><br class="">
> mov @a, %r0  // r0 = gpr<br class="">
> mov %r0, %b1 // b1 = base reg<br class="">
><br class="">
> The register class looks like this:<br class="">
><br class="">
> def ARegs : RegisterClass<"us", [i16], i16, (add GPRRegs, IndexRegs, BaseRegs)>;<br class="">
><br class="">
> I have absolutely no idea why this is not matching any longer?<br class="">
><br class="">
> The fix here is to define an MI with explicit single register class (ie it only allows PTRRegs as the destination).<br class="">
><br class="">
> 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 class="">
><br class="">
> Thanks.<br class="">
</div></div>> _______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a>         <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.cs.uiuc.edu_&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=fK8KXlXNFjX9EyldRbiY4GwaxZBFjvTYEXwRJuFLJvg&e=" target="_blank" rel="noreferrer" class="">http://llvm.cs.uiuc.edu</a><br class="">
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.cs.uiuc.edu_mailman_listinfo_llvmdev&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=TAPJBdWJfY-53g2FEN-kOKTo2nDJxcpEGNpqpgcrN9U&e=" target="_blank" rel="noreferrer" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class="">
<br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></div></div><br class=""></div>
</blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""></div></div><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=N0TOaZZSrDVRpbh_uMG5DV5ZZ2_KVMcBWtK9vGIaByY&e=" target="_blank" class="">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=Kar_gr4lUTX9iRgFLHyIPCR7VD3VlB3-02h_Q5v9oWk&m=7VQTHNyB_IcF4I86741RzVduPmdgCRL_mHUfuUmnL0Y&s=N0TOaZZSrDVRpbh_uMG5DV5ZZ2_KVMcBWtK9vGIaByY&e=</a> <br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>