<div dir="ltr"><div class="gmail_extra"><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"><span class="gmail-"><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="gmail-m_226590172648519399gmail_msg">
unknown as an undef will be a problem?<br class="gmail-m_226590172648519399gmail_msg">
<br class="gmail-m_226590172648519399gmail_msg"></blockquote></div></span></blockquote><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">http://llvm.org/docs/LangRef.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><br></div><div><br></div><div><br></div></div></div></div>