<div dir="ltr">Actually, digging further into it,  I don't understand how this fixes it at all, and your test does nothing because it's all CHECK's :-)<div><br></div><div>The example given in the bug report is or true, undef</div><div><br></div><div>ResolveUndefs already does the right thing for this, and does not consider the result undef.</div><div><br></div><div>The propagation order makes it impossible for that to happen, because in reality, undef is a set of lattice values but not represented in the lattice, and resolveUndefs is trying to figure out the lattice values that work.</div><div><br></div><div>That's ... never going to work, as you've discovered (and eli suspects on the bug report).</div><div><br></div><div>I suspect pretty much every part of markForcedConstant is vulnerable to this undef different circumstances.</div><div><br></div><div>Realistically, undef needs to be an actual lattice value lower than unknown</div><div><br></div><div>That way, or undef, true comes out true during *solving*.</div><div>The parts of resolveundefs handling this need to be made part of the meet operation </div><div><br></div><div>This handles the case where undef must be constrained (IE or undef, true).</div><div><br></div><div>After solving is finished, anything left as undef can then be filled in unconstrained, because you are guaranteed it is not forced to a certain value (or that your solver sucks :P)</div><div><br></div><div>(note that in the freeze/poison proposal, this should just work because the freezes will be different ssa names)</div><div><br></div><div><br></div><div><br></div><div><br></div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 8, 2016 at 4:50 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">So, it looks like what happens here is you expect undef to be a constrainable value.<div><br></div><div>That is, for "or true, undef", you expect it to be true, despite the undef being there.</div><div><br></div><div>Adding an undef expert to say whether this expectation is reasonable.</div><div><br></div><div>(IE whether undef is allowed to have super-magical possibilities, such that the compiler can pick a value that the or returns false).</div><div><br></div><div>Otherwise, FWIW, it seems simple to fix "right" (just constant fold it using the symbolic operands and if it returns true/false, use that)</div><div><br></div><div><br><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 8, 2016 at 4:39 PM, Davide Italiano via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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">davide added a comment.<br>
<br>
This fixes the miscompile reported in PR30448. I tried  on many internal tests and bootstrapping clang, and it works without problems. We lose some optimization power, but it seems that the pattern is rare enough so we shouldn't really worry.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D26432" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2643<wbr>2</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>