[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
Eli Friedman
eli.friedman at gmail.com
Fri Nov 2 14:21:34 PDT 2012
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
More information about the llvm-dev
mailing list