<div dir="ltr">The foldPhiOpArgIntoPhi looks like a few special cases of the general transform (that is applicable as a rewrite rule):<br><br>phi(F(1,2,...), F(A,B,...),...) == F(phi(1,A,...), phi(1,B,...), ...)<div><br></div><div>This follows directly from phis being conditional selects.</div><div><br></div><div>in code:<br><br></div><div><br></div><div>a = b + c</div><div>b = d + e</div><div>result = phi(a, b)</div><div><br></div><div>is equivalent to</div><div><br></div><div>tmp1 = phi(b, d)<br></div><div>tmp2 = phi(c, e)</div><div>result = tmp1 + tmp2</div><div><br></div><div>this is true for any number of operators and operations.</div><div><br></div><div><br></div><div>The downside is fixpointing this rule (and even probably the one being used in foldPhiOpArgIntoPhi) is that it may require exponential applications of the rule.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 30, 2017 at 11:20 AM, Sanjay Patel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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"><div><div>I'm looking at a similar problem in:<br><a href="https://reviews.llvm.org/D28625" target="_blank">https://reviews.llvm.org/D2862<wbr>5</a><br><br></div>Does that patch make any difference on the cases that you are looking at?<br><br></div>Instead of avoiding ShouldChangeType with zext as a special-case opcode, it might be better to treat i1 as a special-case type. There's no way to avoid i1 in IR, so we might as well allow transforming to that type?<br><br>I'm not sure yet, but there's a chance that change might induce problems (infinite loops) with this:<br><a href="https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp#L374" target="_blank">https://github.com/llvm-mirror<wbr>/llvm/blob/master/lib/Transfor<wbr>ms/InstCombine/InstCombineSimp<wbr>lifyDemanded.cpp#L374</a><br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Jan 29, 2017 at 3:09 PM, Björn Steinbrink via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div>Hi,<br><br></div>AFAICT there are two places where zext instructions may get folded into PHI nodes. One is FoldPHIArgZextsIntoPHI and the other is the more generic FoldPHIArgOpIntoPHI. Now, the former only handles PHIs with more than 2 incoming values, while the latter only handles casts where the source type is legal.<br><br>This means that for an PHI node with two incoming i8 values, both resulting from `zext i1 * to i8` instructions, both of these functions will refuse to actually fold the zext into the PHI, while the same operation would be performed if there were three or more arms. We noticed this because we saw a optimization regression when a function got specialized and the PHI node only had two incoming values left.<br><br></div>Since I'm not fully aware of any implications this might have, I wonder what is the right way to fix this? Looking at FoldPHIArgZextsIntoPHI, it seems that making the check for `ShouldChangeType` in FoldPHIArgOpIntoPHI conditional on the cast instruction not being a zext instruction. Does that sound right, or am I missing something here?<br><br></div>Thanks<span class="m_-5484020062485211974HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-5484020062485211974HOEnZb"><font color="#888888">Björn<br></font></span></div>
<br></div></div>______________________________<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></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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></blockquote></div><br></div>