<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 7:59 AM, Daniel Sanders <span dir="ltr"><<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@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;line-break:after-white-space"><br><div><span class=""><br><blockquote type="cite"><div>On 3 Jan 2018, at 19:44, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div><br class="m_-5934941703931715502Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 2, 2018 at 8:28 AM, Daniel Sanders <span dir="ltr"><<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sean,<br>
<br>
Just to give the GlobalISel perspective on this,</blockquote><div><br></div><div>Thanks for chiming in!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> GlobalISel supports the declaration of a zero register in the register class like so:<br>
        def GPR32z : RegisterOperand<GPR32> {<br>
          let GIZeroRegister = WZR;<br>
        }<br>
With that definition, the tablegen-erated ISel code will try to replace will try to replace 'G_CONSTANT s32 0' with WZR whenever the operand is specified as GPR32z.<br></blockquote><div><br></div><div><br></div><div>Is this method extensible to the case of other hardwired register values? Tracing through the code, I noticed that it seems to boil down to a GIR_CopyOrAddZeroReg opcode, which seems like a pretty deep embedding of the specialness of zero.</div></div></div></div></div></blockquote><div><br></div></span><div>At the moment, zero is hardwired since losing an AArch64 optimization was the motivating case behind adding it and the only other hardwired register I knew about was Mips's $0 but I see no reason we couldn't expand on it with a target hook of some kind.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Also, IIUC, GPR32z is defining a special reg class that enables the zero-register transformation. Defining a new reg class seems pretty heavyweight for this; is there ever a situation where you wouldn't want the zero-register transformation to fire so you could just put this on GPR32 itself? I noticed that there actually aren't very many uses of GPR32z which seems strange, as I would expect most instructions could make use of the zero register.</div></div></div></div></div></blockquote><div><br></div></span><div>I haven't got around to rolling it out to GPR32 yet, we think it's safe to do that but there are a couple instructions where wzr/xzr aren't permitted. At the moment, it's on the instructions that lost the optimization when tablegen took over from the C++.</div></div></div></blockquote><div><br></div><div>Makes sense, thanks for the explanation!</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks,</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="m_-5934941703931715502gmail-HOEnZb"><div class="m_-5934941703931715502gmail-h5"><br>
> On 21 Dec 2017, at 21:22, Sean Silva via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I looked around the codebase and didn't see anything that obviously looked like the natural place to turn constant zero immediates into zero-registers (i.e. registers that always return zero when read). Right now we are expanding them in ISelLowering::LowerOperation but that seems too early.<br>
><br>
> The specific issue I'm hitting is that we have a register that reads as -1 and so when we replace -1 too early with this register, the standard "not" pattern (xor x, -1) will fail to match to "not".<br>
><br>
> Thanks,<br>
> Sean Silva<br>
</div></div><div class="m_-5934941703931715502gmail-HOEnZb"><div class="m_-5934941703931715502gmail-h5">> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</div></div></blockquote></div><br></div></div>
</div></blockquote></span></div><br></div></blockquote></div><br></div></div>