<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 30, 2016 at 9:47 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.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 class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-2201429601213893102gmail-"><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  Is there a case in your algorithm in which treating an<br class="m_-2201429601213893102gmail-m_226590172648519399gmail_msg">
unknown as an undef will be a problem?<br class="m_-2201429601213893102gmail-m_226590172648519399gmail_msg">
<br class="m_-2201429601213893102gmail-m_226590172648519399gmail_msg"></blockquote></div></span></blockquote></span><div>Yes, if you try to optimize undefs in any way, no if you move them to overdefined :)</div><div><br></div><div>IE given phi [a, undef, undef, undef]</div><div><br></div><div>with just as many back edges, you will visit this node 4 times.</div><div><br></div><div>If you start out with</div><div><br></div><div>phi [a, undef, undef, undef], you may think "I know, i will make  these undef's a".</div><div><br></div><div>So you move everything to value </div><div><br></div><div>phi [a, a, a, a]</div><div><br></div><div>But remember, you really haven't visited the other 4 edges yet, so you don't know if this is a valid value for undef (because of the rules around and/or/etc, see <a href="http://llvm.org/docs/LangRef.html#undefined-values" target="_blank">http://llvm.org/docs/LangRef.<wbr>html#undefined-values</a>).</div><div><br></div><div>(a, a, a, a of course, is just an example, you also don't know if it's valid to always return undef, or 0, or 1, or anything at all, really).</div><div><br></div><div>It's not until you hit this node for the 4th time, that you can really safely choose a value.</div><div><br></div><div>If you have unknown and undef, it goes from</div><div><br></div><div>phi [a, unknown, unknown, unknown] to phi [a, undef, unknown, unknown] to ...</div><div><br></div><div>you know, once you have no unknown values, that everything you need to know to resolve it is known.</div><div><br></div><div>(this is also why there is no need for a resolver. There really is no safe logic in the resolver that can't be pushed into the solver, though it may make sense to structure it as a resolver if you think it's easier)</div><div><br></div><div>Similarly for or %x, undef.</div><div>You need to know if it's really undef, not "something i haven't visited yet".</div></div></div></div></blockquote><div><br></div><div>Whoops, hit send earlier.</div><div><br></div><div>Most of this gets taken care of by iterating in def-use order, but not for phis or things dependent on them.</div><div><br>(especially if you want to resolve a phi node from a real value to undef)</div><div> </div></div><br></div></div>