<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><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;"><b>From: </b>"Peter Lawrence" <c_plawre@qca.qualcomm.com><br><b>To: </b>"Daniel Berlin" <dberlin@dberlin.org>, "Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Tuesday, June 14, 2016 9:04:16 PM<br><b>Subject: </b>RE: [llvm-dev] Early CSE clobbering llvm.assume<br><br>
<style><!--
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">Daniel,</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> This first part is to whoever you are quoting, I can’t tell from the email,</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">The more information made available to the optimizers the better the optimizations,</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">Asserts provide more information,</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">You *<b>should</b>* expect better code with asserts enabled.</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">And this is *<b>not</b>* a bad thing !!!</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">And IMHO there is no winning argument that says we should not use this information.</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">In other words saying “asserts aren’t for optimization” isn’t a winning argument,</span></p>
<p class="MsoNormal"><span id="DWT9918" style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">Its information and it isn’t useful to throw that information away.</span></p></div></blockquote>Unfortunately, it is not that simple. When asserts are enabled, the conditions they encapsulate need to be checked at runtime. This checking has a cost (especially if the asserted condition is not cheap to compute), and also introduces extra control flow which can inhibit optimization. It might also provide additional information which can help optimization, but generally speaking, in part because of usage conventions (e.g. using expensive-to-compute expressions in the assert), enabling asserts does not generally help performance.<br><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 class="WordSection1"><p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">It’s not very far removed from saying “if, while, and for conditions” aren’t for optimization.</span></p>
<p class="MsoNormal"><span id="DWT9919" style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p></div></blockquote>It is quite far removed.<br><br>Unfortunately, asserts are a feature designed to help debugging, and not optimization. This is why defining NDEBUG turns them off. We would like a feature, similar in spirit, that is intended to help optimization. This is what assume is for. The contracts feature being discussed for C++ also has specific allowances for usage for optimization.<br><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 class="WordSection1"><p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">This second part is for your response,</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">Hmmm, I don’t get how you go from “assert having a call to abort()” to a bunch of talk</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">About “branch around unreachable” ? the condition isn’t unreachable, the abort isn’t</span></p>
<p class="MsoNormal"><span id="DWT9920" style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">Unreachable, what’s unreachable ???</span></p></div></blockquote>I think we're confusing several branches of the conversation here. There actually is an unreachable after the abort because the abort does not return. We were talking, however, about using an alternate representation for assumes which used control flow and unreachable. In this case, there would be no abort, just the unreachable.<br><br> -Hal<br><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 class="WordSection1"><p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">--Peter.</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: "Calibri",sans-serif;">From:</span></b><span style="font-size: 11pt; font-family: "Calibri",sans-serif;"> Daniel Berlin [mailto:dberlin@dberlin.org]
<br>
<b>Sent:</b> Tuesday, June 14, 2016 11:23 AM<br>
<b>To:</b> Hal Finkel <hfinkel@anl.gov><br>
<b>Cc:</b> Lawrence, Peter <c_plawre@qca.qualcomm.com>; llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [llvm-dev] Early CSE clobbering llvm.assume</span></p>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<blockquote style="border-width: medium medium medium 1pt; border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;">
<div>
<blockquote style="border-width: medium medium medium 1.5pt; border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(16, 16, 255); padding: 0in 0in 0in 4pt; margin-left: 3.75pt; margin-top: 5pt; margin-bottom: 5pt;">
<div>
<div>
<div>
<blockquote style="border-width: medium medium medium 1pt; border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); padding: 0in 0in 0in 6pt; margin: 5pt 0in 5pt 4.8pt;">
<div>
<p class="MsoNormal"><span style="font-family: "Helvetica",sans-serif; color: black;"> </span></p>
<p class="MsoNormal" style=""><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</span><span style="color: black;"></span></p>
<p class="MsoNormal" style=""><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><span style="color: black;"></span></p>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;">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.</span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal">:)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;"><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. </span></p>
<p class="MsoNormal"><span style="font-family: "Helvetica",sans-serif; color: black;"> </span></p>
<p class="MsoNormal"><span style="font-family: "Helvetica",sans-serif; color: black;"> </span></p>
<p class="MsoNormal"><span style="font-family: "Helvetica",sans-serif; color: black;">Asserts occur much more often than assumes, it may or may not be sensible to handle them the same way.</span></p>
<p class="MsoNormal"><span style="font-family: "Helvetica",sans-serif; color: black;">I would argue it is sensible, but it's also reasonable to argue it is not.</span></p>
<p class="MsoNormal"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;">We need to be careful what we mean by "in the same way".</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Yes, i simply meant "extract information from the control flow structure and comparisons they generate when they are enabled".</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">You are correct with all of your observations :)</p>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 10pt; font-family: "Arial",sans-serif; color: black;"><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></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>