[llvm-dev] The undef story

[Peter Lawrence via llvm-dev]

> On Jun 29, 2017, at 9:32 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
>>> 
>>> On Jun 29, 2017, at 4:39 AM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote:
>>> 
>>> On 06/28/2017 05:33 PM, Peter Lawrence wrote:
>>>> Chandler,
>>>>                where we disagree is in whether the current project is moving the issue
>>>> forward.  It is not.  It is making the compiler more complex for no additional value.
>>>> 
>>>> The current project is not based in evidence, I have asked for any SPEC benchmark
>>>> that shows performance gain by the compiler taking advantage of “undefined behavior”
>>>> and no one can show that.
>>> 
>>> 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:
>>> 
>>> template <typename T>
>>> int do_something(T mask, bool cond) {
>>>   if (mask & 2)
>>>     return 1;
>>> 
>>>   if (cond) {
>>>     T high_mask = mask >> 48;
>>>     if (high_mask > 5)
>>>       do_something_1(high_mask);
>>>     else if (high_mask > 3)
>>>       do_something_2();
>>>   }
>>> 
>>>   return 0;
>>> }
>>> 

Hal,
       yes, there are times when it is expedient to suppress or ignore warnings,
but I don’t believe this is one of them, a suggestion could have been made
to change the source code along the lines of

    If (48 < 8*sizeof(mask)  && Cond)

Sizeof is always a compile-time constant, this would always be used to dead-code
eliminate the offending block, no "undefined behavior”, no warning, and no
performance issue.

So I respectfully remain skeptical until I see a real world source code example 
where "optimizing away undefined behavior” is of benefit.


Peter Lawrence.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170701/09982800/attachment.html>