<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_extra"><span class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><br>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Sanjoy’s argument is faulty, if it were true we would also find our handling of “assert” to be unacceptable<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">but this is not the case, no one is arguing that we need to re-design “assert”</span></p></div></blockquote></div></span></div></div></blockquote>Sure, but no one should make this argument anyway: assert is not for optimization. In fact, we don't really want it to be used for optimization, because if we do, then we might end up in a situation where the -DNDEBUG build generates worse code than the build with asserts enabled.<br></div></blockquote><div><br></div><div>:)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br>Also, I'll note that the reason that assume is an intrinsic, instead of a branch around unreachable, is that we aggressively remove branches around unreachable as part of our canonicalization process. We do this in order to simplify code, and this is important in order to remove abstraction penalties. Note that unreachables are also generated from undefined behavior, and one of the ways we use undefined behavior is to assume it is unreachable, enabling us to eliminate what should be dead code. This is an important technique for limiting abstraction penalties from, for example, heavily templated C++ code.<br><br>Thus, somewhat unfortunately, Sanjoy's argument is not faulty. <br><span class=""><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"></span></p></div></div></blockquote><br><div><br></div><div>Asserts occur much more often than assumes, it may or may not be sensible to handle them the same way.</div><div>I would argue it is sensible, but it's also reasonable to argue it is not.</div></div></div></div></blockquote></span>We need to be careful what we mean by "in the same way".</div></div></blockquote><div><br></div><div>Yes, i simply meant "extract information from the control flow structure and comparisons they generate when they are enabled".</div><div><br></div><div>You are correct with all of your observations :)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br>We can certainly improve the representations of assumes, perhaps as Danny has suggested by converting their control dependencies into extended SSA token vales, and better capture knowledge from conditional branches, but the tradeoffs here are not trivial.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div></div></blockquote><div><br></div><div>100% agreed, this is something that requires some exploration and messing around, and then a design document going through the tradeoffs of various approaches with real data.</div><div><br></div></div></div></div>