<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:58 AM, Daniel Sanders <<a href="mailto:daniel_l_sanders@apple.com" class="">daniel_l_sanders@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 20, 2019, at 10:04, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" 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></div></blockquote><div class=""><br class=""></div><div class="">That's not as easy as you make it sound :-) but let's suppose we can recognize enough of the underlying pattern to be able to use getConstantVRegVal() instead of needing to do a direct translation of the SelectionDAG pattern. In the SelectionDAG patterns an ImmLeaf is an `imm` node with arbitrary C++ predicate(s) attached. There's no practical way to programatically fold a sext/zext/trunc node into the arbitrary C++ code to allow it to match a plain G_CONSTANT, as well as a zexted/sexted/trunced G_CONSTANT. For example, `isUInt<16>(Imm)` will fail if you want it to match (sext (imm):<<Predicate>>) as if it were (sext (imm)):<<Predicate>> because there's no way to understand that we need to replace the isUInt<16> with isInt<16> when we hoist the predicate up.</div></div></div></div></blockquote><div><br class=""></div><div>I was naively thinking we could replace any check of G_CONSTANT with <span style="color: rgb(180, 36, 25); font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class=""><b class="">getConstantVRegVal</b></span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class="">WithLookThrough</span>, but indeed, I have no idea what it would take :).</div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><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 type="cite" 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.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="">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.</div></div></div></blockquote></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">As Quentin notes, getConstantVRegVal() can't look through trunc/zext/sext</div></div></div></div></blockquote><div><br class=""></div><div>But <span style="color: rgb(180, 36, 25); font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class=""><b class="">getConstantVRegVal</b></span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class="">WithLookThrough c</span>an (with the right arguments, IIRC).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""> either so that change by itself wouldn't resolve the issue by itself. The main issue here is that the the SelectionDAG pattern importer is following the semantics of SelectionDAG patterns which in this case is that each node in the pattern (after expanding PatFrag) corresponds to a SelectionDAG node. If the patterns rely on optimizations happening prior to instruction selection then those either same optimizations need implementing or the patterns need extending to support the additional cases. At the moment, it's fairly common to have some C++ instruction selection or additional patterns (usually C++ as many of the targets pre-date the SelectionDAG importer) filling in the gaps in the imported rules.</div><div class=""><br class=""></div><div class="">There's fairly limited support for constant folding at the moment. There's a ConstantFoldingMIRBuilder which folds when instructions are created and a CSEMIRBuilder which also constant folds at the same time as CSE'ing. I just had a quick look at them and it seems we only constant fold binary operations. I just asked Aditya (who added it) about this and the main issue is identifying that a new G_CONSTANT is legal for unary operations that change the type of the constant like G_ZEXT/G_SEXT/G_TRUNC.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: 'Helvetica Neue',Helvetica,Arial,sans-serif; font-size: 12px;" 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></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>