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

Krzysztof Parzyszek kparzysz at codeaurora.org
Thu Nov 1 18:41:30 PDT 2012


On 11/1/2012 6:38 PM, Michael Ilseman wrote:
>
> On Nov 1, 2012, at 3:08 PM, Dan Gohman <dan433584 at gmail.com
> <mailto:dan433584 at gmail.com>> wrote:
>>
>> If the "optimizer" may truly ignore the possibility of NaNs under the
>> N flag, this would seem to be ok. However, a trap is outside the
>> boundaries of "undefined result". So, which half is right?
>>
>
> That makes sense, I was thinking of things only in terms of the
> optimizer and not in terms of instruction selection. Which do you think
> is better, Undefined Behavior or that instruction selection should
> disregard those bits? I'd lean towards undefined behavior, but I don't
> have a good feel for LLVM's overall design for undefined behavior,
> poison values, etc.

I still don't understand Dan's concerns, but a target that traps on a 
quiet NaN is not IEEE compliant.  IEEE754 requires that quiet NaNs get 
propagated through operands to the results without causing exceptions.

-Krzysztof

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



More information about the llvm-dev mailing list