<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 06/29/2017 10:41 AM, Peter Lawrence
wrote:<br>
</div>
<blockquote
cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jun 29, 2017, at 4:39 AM, Hal Finkel <<a
moz-do-not-send="true" href="mailto:hfinkel@anl.gov"
class="">hfinkel@anl.gov</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">On 06/28/2017 05:33 PM, Peter
Lawrence wrote:<br class="">
</div>
<blockquote
cite="mid:37027DE0-B3CC-47C2-907C-C5A7A5A97BD1@sbcglobal.net"
type="cite" class="">Chandler,
<div class=""> where we disagree is in
whether the current project is moving the issue</div>
<div class="">forward. It is not. It is making the
compiler more complex for no additional value.</div>
<div class=""><br class="">
</div>
<div class="">The current project is not based in
evidence, I have asked for any SPEC benchmark</div>
<div class="">that shows performance gain by the
compiler taking advantage of “undefined behavior”</div>
<div class="">and no one can show that.</div>
</blockquote>
<br class="">
I can't comment on SPEC, but this does remind me of code I
was working on recently. To abstract the relevant parts,
it looked something like this:<br class="">
<br class="">
template <typename T><br class="">
int do_something(T mask, bool cond) {<br class="">
if (mask & 2)<br class="">
return 1;<br class="">
<br class="">
if (cond) {<br class="">
T high_mask = mask >> 48;<br class="">
if (high_mask > 5)<br class="">
do_something_1(high_mask);<br class="">
else if (high_mask > 3)<br class="">
do_something_2();<br class="">
}<br class="">
<br class="">
return 0;<br class="">
}<br class="">
<br class="">
This function ended up being instantiated on different
types T (e.g. unsigned char, unsigned int, unsigned long,
etc.) and, dynamically, cond was always false when T was
char. The question is: Can the compiler eliminate all of
the code predicated on cond for the smaller types? In this
case, this code was hot, and moreover, performance
depended on the fact that, for T = unsigned char, the
function was inlined and the branch on cond was
eliminated. In the relevant translation unit, however, the
compiler would never see how cond was set.<br class="">
<br class="">
Luckily, we do the right thing here currently. In the case
where T = unsigned char, we end up folding both of the
high_mask tests as though they were false. That entire
part of the code is eliminated, the function is inlined,
and everyone is happy.<br class="">
<br class="">
Why was I looking at this? As it turns out, if the 'else
if' in this example is just 'else', we don't actually
eliminate both sides of the branch. The same is true for
many other variants of the conditionals (i.e. we don't
recognize all of the code as dead).</div>
</div>
</blockquote>
<div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>I apologize in advance if I have missed something here
and am misreading your example...</div>
<div class=""><br class="">
</div>
</div>
<div>This doesn’t make sense to me, a shift amount of 48 is
“undefined” for unsigned char,</div>
<div>How do we know this isn’t a source code bug,</div>
<div>What makes us think the the user intended the result to be
“0”.</div>
</div>
</blockquote>
<br>
As I said, this is representation of what the real code did, and
looked like, after other inlining had taken place, etc. In the
original form, the user's intent was clear. That code is never
executed when T is a small integer type.<br>
<br>
<blockquote
cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
type="cite">
<div>
<div><br class="">
</div>
<div>This strikes me as odd, we are mis-interpreting the user’s
code </div>
<div>In such a way so as to improve performance, but that isn’t
necessarily what the user intended.</div>
</div>
</blockquote>
<br>
That is exactly what the user intended. That's why I brought it up
as an example.<br>
<br>
<blockquote
cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
type="cite">
<div>
<div><br class="">
</div>
<div>Here’s one way to look at this issue, if something is “C
undefined behavior” then</div>
<div>The standard says, among other things, that we could trap
here</div>
<div>Why aren’t we doing that rather than optimizing it ?</div>
</div>
</blockquote>
<br>
We could. In fact, we have great tools (UBSan, ASan, etc.) that will
instrument the code to do exactly that.<br>
<br>
<blockquote
cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
type="cite">
<div>
<div><br class="">
</div>
<div>Here’s another way to look at it, no one has ever filed a
bug that reads</div>
<div>“I used undefined behavior in my program, but the optimizer
isn’t taking advantage of it”</div>
</div>
</blockquote>
<br>
You say that as though it is true. It is not. Yes, users file bugs
like that (although they don't often phrase it as "undefined
behavior", but rather, "the compiler should figure out that...", and
often, taking advantage of UB is the only available way for the
compiler to figure that thing out). Type-based aliasing rules are
another common case where this UB-exploitation comes up (although
not in a way that directly deals with undef/poison).<br>
<br>
<blockquote
cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
type="cite">
<div>
<div>But if they do I think the response should be </div>
<div>“you should not expect that, standard says nothing positive
about what undefined behavior does"</div>
<div><br class="">
</div>
</div>
</blockquote>
<br>
And, of course, often we do have to tell our users that the compiler
has no way to figure something out. When we have a tool, and
sometimes that tool is exploiting our assumptions that UB does not
happen, then we use it. You may disagree with decisions to exploit
certain classes of UB is certain situations, and that's fine. We do
use our professional judgment and experience to draw a line
somewhere in this regard.<br>
<br>
<blockquote
cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
type="cite">
<div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""> Once we have
a self-consistent model for undef, we should be able to
fix that. The user was confused, however, why seemingly
innocuous changes to the code changed the performance
characteristics of their application. The proposed
semantics by John, et al. should fix this uniformly.<br
class="">
<br class="">
In any case, to your point about:<br class="">
<br class="">
<blockquote type="cite" class="">
<div style="margin: 0px; font-size: 14px; line-height:
normal; font-family: Menlo; background-color: rgb(255,
255, 255);" class=""><span
style="font-variant-ligatures: no-common-ligatures"
class=""> if (a == a)</span></div>
<div style="margin: 0px; font-size: 14px; line-height:
normal; font-family: Menlo; background-color: rgb(255,
255, 255);" class=""><span
style="font-variant-ligatures: no-common-ligatures"
class=""> S;</span></div>
</blockquote>
<br class="">
I have the same thought. If a == undef here, the code
should be dead. Dead code must be aggressively dropped to
enable inlining and further optimization. This is an
important way we eliminate abstraction penalties. Dead
code also has costs in terms of register allocation,
speculative execution, inlining, etc.<br class="">
<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>And yet IIRC Sanjoy in his last email was arguing for
consistent behavior in cases like</div>
<div>If (x != 0) {</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>/*
we can optimize in the then-clause assuming x != 0 */</div>
<div>}</div>
<div>And in the case above when it is a function that gets
inlined</div>
</div>
</blockquote>
<br>
I don't believe these are contradictory statements. In the proposed
semantics, we get to assume that branching on poison is UB, and
thus, doesn't happen. So, if it were inevitable on some code path,
that code path must be dead.<br>
<br>
<blockquote
cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
type="cite">
<div>
<div><br class="">
</div>
<div>Here’s what Sanjoy said about the function-inline case</div>
<div><br class="">
> This too is fixed in the semantics mentioned in the
paper. This also<br class="">
> isn't new to us, it is covered in section 3.1 "Duplicate
SSA Uses".<br class="">
</div>
<div><br class="">
</div>
<div>So this issue seems to be up in the air</div>
<div><br class="">
</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""> I've also
seen cases where templated types are used with fixed-sized
arrays where the compiler to leveraged knowledge of UB on
uninitialized values and out-of-bounds accesses to
eliminate unnecessary part of the code. In short,
"optimizing on undefined behavior" can end up being an
important tool.<br class="">
<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>As you can tell from my first comments, I am not yet
convinced, and would still like to see real evidence</div>
</div>
</blockquote>
<br>
I understand. However, to say that it is not useful to optimize
based on UB, even explicit UB, or that this is never something that
users desire, is not true.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:8D1216F2-8E1C-4895-8DA2-19932A92BD1B@sbcglobal.net"
type="cite">
<div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>Peter Lawrence.</div>
<div><br class="">
</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""> -Hal<br
class="">
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>