[llvm-dev] The undef story

Hal Finkel via llvm-dev
2017-07-01T20:24:54Z

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>