[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