llvm dev - Nov 2012 - [LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level

On 11/2/2012 11:53 AM, Michael Ilseman wrote:
>
>
> I think Dan was making two points with his example. Dan, correct me if I
misrepresent your example, but image a situation where a target has two
instructions to choose between in order to perform the operation. The first is
IEEE compliant, but the second isn't compliant in how it operates over NaNs
(quiet or otherwise). For whatever reason, the second is preferred when we know
inputs are not NaN.
>
> The first point is that I didn't specify if the N bit would allow the
target to choose the non-compliant operation.
>
> The second point is that my specifying "undefined value"
isn't enough. What if the non-compliant instruction's behavior on NaN
was to trap. It's not just an invalid/random bit pattern, but actual
behavioral differences.
I see.  The situation is that the user tells the compiler to "ignore" 
NaNs, and yet the program does produce a NaN.  The compiler generates 
the trapping instruction (expecting that the trap won't happen), but 
because of the NaN, the trap does occur.

My definition of the N flag would be that it instructs the compiler that 
the computations do not involve or produce NaNs.  In other words, when, 
as a programmer, I use the N flag, I'm telling the compiler that I don't
expect NaNs to ever appear in the computations.  If a NaN did appear and 
produced a trap, it would be just as unexpected as seeing a NaN in the 
output without a trap.

The same would apply to infinities.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

On Fri, Nov 2, 2012 at 10:02 AM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> On 11/2/2012 11:53 AM, Michael Ilseman wrote:
>
>>
>>
>> I think Dan was making two points with his example. Dan, correct me if
I
>> misrepresent your example, but image a situation where a target has two
>> instructions to choose between in order to perform the operation. The
first
>> is IEEE compliant, but the second isn't compliant in how it
operates over
>> NaNs (quiet or otherwise). For whatever reason, the second is preferred
>> when we know inputs are not NaN.
>>
>> The first point is that I didn't specify if the N bit would allow
the
>> target to choose the non-compliant operation.
>>
>> The second point is that my specifying "undefined value"
isn't enough.
>> What if the non-compliant instruction's behavior on NaN was to
trap. It's
>> not just an invalid/random bit pattern, but actual behavioral
differences.
>>
>
That's right.

>
> I see.  The situation is that the user tells the compiler to
"ignore"
> NaNs, and yet the program does produce a NaN.  The compiler generates the
> trapping instruction (expecting that the trap won't happen), but
because of
> the NaN, the trap does occur.
>
> My definition of the N flag would be that it instructs the compiler that
> the computations do not involve or produce NaNs.  In other words, when, as
> a programmer, I use the N flag, I'm telling the compiler that I
don't
> expect NaNs to ever appear in the computations.  If a NaN did appear and
> produced a trap, it would be just as unexpected as seeing a NaN in the
> output without a trap.
>
Just so you know, what you're describing sounds like Undefined Behavior.

I don't currently have a suggestion for what is best choice is, or of how
important it is.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121102/6f00be75/attachment.html>

On 11/2/2012 3:07 PM, Dan Gohman wrote:
>
>
> Just so you know, what you're describing sounds like Undefined
Behavior.
>
> I don't currently have a suggestion for what is best choice is, or of
> how important it is.
>
I believe that the "undefined behavior" approach is clearer, and
easier
to understand (for the users who will be providing such flags).

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

On Fri, Nov 2, 2012 at 1:07 PM, Dan Gohman <dan433584 at gmail.com>
wrote:
>
>
> On Fri, Nov 2, 2012 at 10:02 AM, Krzysztof Parzyszek
> <kparzysz at codeaurora.org> wrote:
>>
>> On 11/2/2012 11:53 AM, Michael Ilseman wrote:
>>>
>>>
>>>
>>> I think Dan was making two points with his example. Dan, correct me
if I
>>> misrepresent your example, but image a situation where a target has
two
>>> instructions to choose between in order to perform the operation.
The first
>>> is IEEE compliant, but the second isn't compliant in how it
operates over
>>> NaNs (quiet or otherwise). For whatever reason, the second is
preferred when
>>> we know inputs are not NaN.
>>>
>>> The first point is that I didn't specify if the N bit would
allow the
>>> target to choose the non-compliant operation.
>>>
>>> The second point is that my specifying "undefined value"
isn't enough.
>>> What if the non-compliant instruction's behavior on NaN was to
trap. It's
>>> not just an invalid/random bit pattern, but actual behavioral
differences.
>
>
> That's right.
>
>>
>>
>> I see.  The situation is that the user tells the compiler to
"ignore"
>> NaNs, and yet the program does produce a NaN.  The compiler generates
the
>> trapping instruction (expecting that the trap won't happen), but
because of
>> the NaN, the trap does occur.
>>
>> My definition of the N flag would be that it instructs the compiler
that
>> the computations do not involve or produce NaNs.  In other words, when,
as a
>> programmer, I use the N flag, I'm telling the compiler that I
don't expect
>> NaNs to ever appear in the computations.  If a NaN did appear and
produced a
>> trap, it would be just as unexpected as seeing a NaN in the output
without a
>> trap.
>
>
> Just so you know, what you're describing sounds like Undefined
Behavior.
>
> I don't currently have a suggestion for what is best choice is, or of
how
> important it is.
It's worth noting that choosing "undefined behavior" could force
passes like LICM to strip the flags.

-Eli