<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 2:32 PM, Peter Lawrence via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>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>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></blockquote><div><br></div><div><br></div><div>Hi Peter, were you able to get set up with LLVM's test-suite?</div><div><br></div><div>As Tim helpfully mentioned, you should be able to compile test-suite as 32-bit on your Mac without issues by using the -m32 flag like usual.</div><div><br></div><div>Once you have that set up and have measured the performance impact of -fwrapv, pinpointing the causes of any regressions would be a good place to start. I understand that you feel like you have a strong intuition about this and aren't expecting any regressions, but you really need to put that to the test for us to take you seriously, as our intuition is the opposite (and usually backed up by specific examples from our professional experience, like the example that Hal mentioned).</div><div><br></div><div>-- Sean Silva </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><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="gmail-HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Peter Lawrence.</div></font></span><div><div class="gmail-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:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="gmail-m_1515375982079837856gmail-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="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>if (mask & 2)<br>   <span class="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>return 1;<br><br> <span class="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>if (cond) {<br>   <span class="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>T high_mask = mask >> 48;<br>   <span class="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>if (high_mask > 5)<br>     <span class="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>do_something_1(high_mask<wbr>);<br>   <span class="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>else if (high_mask > 3)<br>     <span class="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>do_something_2();<br> <span class="gmail-m_1515375982079837856gmail-m_-3269729547621288564Apple-converted-space"> </span>}<br><br> <span class="gmail-m_1515375982079837856gmail-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 href="https://godbolt.org/g/YYtsxB" target="_blank">https://godbolt.org/g/YYtsxB</a> and <a 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><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>