<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 9, 2016 at 11:16 AM, 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"><div class="HOEnZb"><div class="h5">On Wed, Nov 9, 2016 at 9:49 AM, Daniel Berlin via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Actually, digging further into it,  I don't understand how this fixes it at<br>
> all, and your test does nothing because it's all CHECK's :-)<br>
><br>
> The example given in the bug report is or true, undef<br>
><br>
> ResolveUndefs already does the right thing for this, and does not consider<br>
> the result undef.<br>
><br>
> The propagation order makes it impossible for that to happen, because in<br>
> reality, undef is a set of lattice values but not represented in the<br>
> lattice, and resolveUndefs is trying to figure out the lattice values that<br>
> work.<br>
><br>
> That's ... never going to work, as you've discovered (and eli suspects on<br>
> the bug report).<br>
><br>
> I suspect pretty much every part of markForcedConstant is vulnerable to this<br>
> undef different circumstances.<br>
><br>
> Realistically, undef needs to be an actual lattice value lower than unknown<br>
><br>
> That way, or undef, true comes out true during *solving*.<br>
> The parts of resolveundefs handling this need to be made part of the meet<br>
> operation<br>
><br>
> This handles the case where undef must be constrained (IE or undef, true).<br>
><br>
> After solving is finished, anything left as undef can then be filled in<br>
> unconstrained, because you are guaranteed it is not forced to a certain<br>
> value (or that your solver sucks :P)<br>
><br>
> (note that in the freeze/poison proposal, this should just work because the<br>
> freezes will be different ssa names)<br>
><br>
<br>
</div></div>Uh, thanks. Out of curiosity, do you happen to know why undef wasn't<br>
represented as a lattice value from the beginning (and instead we end<br>
up trying values that match up?) Is there a particular reason (e.g.<br>
efficiency)? I can't think of one.<br></blockquote><div><br></div><div>Our SCCP code dates back to 2001, undef arrived in 2004.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--<br>
Davide<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">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>
</div></div></blockquote></div><br></div></div>