<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 20, 2019, at 11:19, via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: 'Helvetica Neue',Helvetica,Arial,sans-serif; font-size: 12px;" class=""><div class="">Hi Quentin,</div><div class=""><br class=""></div><div class="">Thank you for the peace of mind, it was really hard to know I hadn't missed an "EnableConstantFolding=1" line somewhere.<br class=""></div><div class=""><br class=""></div><div class="">I'll apply a dirty hack at my end to make it work - there's quite a bit of legalization on this target.</div><div class=""><br class=""></div><div class="">Another quick one if I may. Is there a better Legalizer-like pass for reducing constant ranges? I find if I have a call at the top of a single-basic-block function, the register allocator will use every single callee-saved reg to store constants across the function call necessitating a heap of spilling. I note the Legalizer is described as only really being useful on allocators that do not rematerialize, but none of the register allocators I've tried seem to attempt to reduce callee-saved-spilling by narrowing constant ranges. The Legalizer itself also does not move within the same basic block, so it does nothing to prevent this problem either<br class=""></div><div class=""><br class="">Missing a pass/setting, or is this for future improvement?</div></div></div></blockquote><div><br class=""></div><div>The constants being in the first block is part of a memory optimization to minimize the number of duplicate constants. The intent is that since matches can reach across blocks, they are effectively sunk by a successful match and hopefully end up dead as a result. If that doesn't happen then we'll rely on other MIR passes sinking them to sensible places. Off-hand, I'm not sure which pass normally does the sinking of the remaining constants. I think it's probably RegisterCoalescer or something along those lines</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: 'Helvetica Neue',Helvetica,Arial,sans-serif; font-size: 12px;" class=""><div class=""><div style="font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-variant-east-asian: normal; font-variant-position: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; word-spacing: 0px;" class="">Cheers!<br class=""></div></div><div class=""><b class=""></b><i class=""></i><u class=""></u><sub class=""></sub><sup class=""></sup><strike class=""></strike><br class=""></div><div class="">----- Original Message -----<br class=""></div><blockquote class=""><div style="width:100%;background:rgb(228,228,228);" class=""><div style="font-weight:bold;" class="">From:</div> "Quentin Colombet" <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>></div><br class=""><div style="font-weight:bold;" class="">To:</div><<a href="mailto:alex.davies@iinet.net.au" class="">alex.davies@iinet.net.au</a>><br class=""><div style="font-weight:bold;" class="">Cc:</div>"llvm-dev" <<a href="mailto:llvm-dev@listsllvm.org" class="">llvm-dev@listsllvm.org</a>>, "Daniel Sanders" <<a href="mailto:daniel_l_sanders@apple.com" class="">daniel_l_sanders@apple.com</a>>, "Amara Emerson" <<a href="mailto:aemerson@apple.com" class="">aemerson@apple.com</a>>, "Matt Arsenault" <<a href="mailto:arsenm2@gmail.com" class="">arsenm2@gmail.com</a>>, "Aditya Nandakumar" <<a href="mailto:aditya_nandakumar@apple.com" class="">aditya_nandakumar@apple.com</a>>, "Volkan Keles" <<a href="mailto:vkeles@apple.com" class="">vkeles@apple.com</a>>, "Jessica Paquette" <<a href="mailto:jpaquette@apple.com" class="">jpaquette@apple.com</a>><br class=""><div style="font-weight:bold;" class="">Sent:</div>Mon, 20 May 2019 10:04:56 -0700<br class=""><div style="font-weight:bold;" class="">Subject:</div>Re: [llvm-dev] GlobalISel: Very limited pattern matching?<br class=""><br class=""><br class="">
+gisel folks<div class=""><br class=""></div><div class="">Hi Alex,</div><div class=""><br class=""></div><div class="">You’re doing the right thing.</div><div class="">That’s a known limitation that we’ve discussed in <a href="https://reviews.llvm.org/D59227" class="">https://reviews.llvm.org/D59227</a> but we didn’t really reach a conclusion back them.</div><div class="">Short term, I believe you’re right, we should patch up the GISel emitter to use <span style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;" class="">getConstantVRegVal instead of looking directly for G_CONSTANT.</span></div><div class=""><font face="Helvetica Neue, Helvetica, Arial, sans-serif" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue, Helvetica, Arial, sans-serif" class="">Long term, this is something we need to discuss I personally think that we shouldn’t consider G_CONSTANT as true instructions and we should always extend them in place, but this is not a generally belief.</font></div><div class=""><font face="Helvetica Neue, Helvetica, Arial, sans-serif" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue, Helvetica, Arial, sans-serif" class="">Cheers,</font></div><div class=""><font face="Helvetica Neue, Helvetica, Arial, sans-serif" class="">-Quentin<br class=""></font><div class=""><br class=""><blockquote class=""><div class="">On May 20, 2019, at 5:49 AM, via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvmorg</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:12px;" class="">Hi all,<br class=""><br class=""><div class="">I'm trying to get GlobalISel up and running on an off-tree architecture and am thinking I must be doing something wrong, given by how few things actually work.</div><div class=""><br class=""></div><div class="">Namely, any ImmLeaf<> pattern will fail to match if there is a (TRUNC/ZEXT/SEXT) applied to the constant operand, all of which are commonly created through Legalization. This is due to G_CONSTANT being explicitly looked for by the tablegened code, rather than code that makes use of getConstantVRegVal.<br class=""></div><br class=""><div class="">Is there supposed to be a constant folding pass before Instruction Selection? CSE does not fold past unaries applied to operands, I'm surely missing a pass somewhere...</div><div class=""><br class="">Thanks,<br class=""></div><div class="">- Alex Davies</div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div><br class=""></div>
</blockquote></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>