Krzysztof Parzyszek
2012-Nov-02 01:41 UTC
[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
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
Michael Ilseman
2012-Nov-02 16:53 UTC
[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
On Nov 1, 2012, at 6:41 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:> 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. >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. My question is whether to approach this by saying that the flags are for the optimizer only, and targets must ignore them, or to say that targets are free to use them and the operation has undefined behavior over, e.g., NaN.> -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Krzysztof Parzyszek
2012-Nov-02 17:02 UTC
[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
Maybe Matching Threads
- [LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
- [LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
- [LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
- [LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
- [LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level