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

[Dan Gohman]

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>