[llvm-dev] The undef story

[Hal Finkel via llvm-dev]

On 07/01/2017 10:10 AM, Peter Lawrence wrote:
>
>> On Jun 29, 2017, at 9:32 AM, Hal Finkel <hfinkel at anl.gov 
>> <mailto: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)

If the logic represented were presented at the source level as in the 
example, I'd completely agree with you. In the real code, neither was 
the 48 directly present as a constant operand of the shift (it ended up 
that way only after inlining) nor was the body of the if (Cond) directly 
present in that function (that, again, happened only after inlining). 
Thus, there was no warning to be avoided nor any obvious condition to 
add to the 'if'.

>
> 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.

Acknowledged.

  -Hal

>
>
> Peter Lawrence.
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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