<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 06/29/2017 04:49 PM, Mehdi AMINI
wrote:<br>
</div>
<blockquote
cite="mid:CANF-O=ZOR-L2=Hyq6XuN-nm=yDs7CMdGNJ9hav9LAFreOOL3Wg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-06-29 14:32 GMT-07:00 Peter
Lawrence <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:peterl95124@sbcglobal.net" target="_blank">peterl95124@sbcglobal.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Mehdi,
<div> I think the following was the point of
the conversation,</div>
<div>That both those examples are illegal C programs.</div>
<div>They are both “undefined behavior” because they
both</div>
<div>use a shift amount that is too large.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Can you confirm that even if the shift isn't executed
the program exhibits undefined behavior?</div>
<div>That wasn't my understanding, so I don't believe this
program exhibits UB.</div>
</div>
</div>
</div>
</blockquote>
<br>
That's correct. The program does not exhibit UB. The too-large-shift
is never dynamically reached. Furthermore, that's the point. Using
the fact that we assume the program does not have UB, and the
program did not have UB, to prune dead code out of some of the
instantiated templates, was a good thing.<br>
<br>
Regarding whether it should be rejected by the compiler, it
shouldn't. If you put the source I put in the email through Clang,
it will indeed warn about the shift amount. A user is free to use
-Werror, or similar, if they'd like such warnings to be an error. In
the real code, the shift amount was only available after inlining,
so the frontend could not have generated a warning or error
directly.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CANF-O=ZOR-L2=Hyq6XuN-nm=yDs7CMdGNJ9hav9LAFreOOL3Wg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>They both should have been rejected by the compiler</div>
<div>even though they weren’t.</div>
<div>Hal agrees wth this assessment,</div>
</div>
</blockquote>
<div><br>
</div>
<div>I'm surprise by the confidence you're exhibiting while
speaking for others.</div>
<div><br>
</div>
<div>-- </div>
<div>Mehdi</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>That’s why we’re waiting for a more complete
example.</div>
<div><br>
</div>
<div>My belief is that undefined behavior is an
optimization hazard,</div>
<div>Not an optimization opportunity. Its just a
belief, I could be proved</div>
<div>Wrong at any moment, but it feels right to me.</div>
<div><br>
</div>
<div>I would start looking for a more complete example
myself, but my</div>
<div>Belief is so strong that "optimizing undefined
behavior" seems </div>
<div>like a self-contradiction to me, and I don’t know
where to</div>
<div>Even start looking.</div>
<div><br>
</div>
<div>I write compiler test programs in my spare time as
a hobby,</div>
<div>(which someday I’d like to contribute to llvm)</div>
<div>So it’s not like I don’t have the knowledge or the
inclination,</div>
<div>I just don’t know how to approach this problem.</div>
<div><br>
</div>
<div><br>
</div>
<div>You would think that since “optimization of
undefined behavior”</div>
<div>Has become such a bedrock concept in llvm that by
now some</div>
<div>Concrete examples would be readily at hand,</div>
<div>But this doesn’t seem to be the case.</div>
<div><br>
</div>
<div>So I’m eagerly awaiting Hal’s (or anyone else's)
next email</div>
<div>That has a complete example.</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div><br>
</div>
<div>Peter Lawrence.</div>
</font></span>
<div>
<div class="h5">
<div><br>
</div>
<div><br>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div
class="m_-1990967588241278101gmail-h5">
<div>
<blockquote type="cite">
<div>
<blockquote type="cite"
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
<div>
<blockquote
type="cite">
<div>
<div
bgcolor="#FFFFFF"><br>
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>
<br>
template
<typename
T><br>
int
do_something(T
mask, bool
cond) {<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>if
(mask & 2)<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>return
1;<br>
<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>if
(cond) {<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>T
high_mask =
mask >>
48;<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>if
(high_mask
> 5)<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>do_something_1(high_mask<wbr>);<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>else
if (high_mask
> 3)<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>do_something_2();<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>}<br>
<br>
<span
class="m_-1990967588241278101gmail-m_-3269729547621288564Apple-converted-space"> </span>return
0;<br>
}<br>
<br>
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>
<br>
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>
<br>
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>
</div>
<div><br>
</div>
<div>I apologize
in advance if I
have missed
something here
and am
misreading your
example...</div>
<div><br>
</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
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
<span
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline">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.</span><br
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
</div>
</blockquote>
<br>
</div>
<div><br>
</div>
</div>
</div>
<div>I will still have a hard time
believing this until I see a
real example, can you fill in
the details ?</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Hal gave you a real example, have
you tried? I feel like you're asking
more effort from others than you are
ready to put in: it took me less
than 5 minutes to reproduce what Hal
was describing using his snippet:</div>
<div><br>
</div>
<div>See the difference between <a
moz-do-not-send="true"
href="https://godbolt.org/g/YYtsxB"
target="_blank">https://godbolt.org/g/YYtsxB</a>
and <a moz-do-not-send="true"
href="https://godbolt.org/g/dTBBDq"
target="_blank">https://godbolt.org/g/<wbr>dTBBDq</a></div>
<div><br>
</div>
<div>-- </div>
<div>Mehdi</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</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>