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

[Michael Ilseman]

On Nov 1, 2012, at 3:08 PM, Dan Gohman <dan433584 at gmail.com> wrote:

> On Tue, Oct 30, 2012 at 8:28 PM, Michael Ilseman <milseman at apple.com> wrote:
>  
> This is similar to how gcc defines -fno-signed-zeros:
> "Allow optimizations for floating point arithmetic that ignore the signedness of zero. IEEE arithmetic specifies the behavior of distinct +0.0 and -0.0 values, which then prohibits simplification of expressions such as x+0.0 or 0.0*x (even with -ffinite-math-only). This option implies that the sign of a zero result isn't significant."
> 
> I'll revise my description to also mention that the sign of a zero result isn't significant. 
> 
> Ok, I see what you're saying here now.
>  
> 
>> Also, even when you do have the second sentence, it seems to contradict the first sentence.
>> 
> 
> Why does it contradict the first sentence? I meant it as a clarification or reinforcement of the first, not a contradiction.
> 
> Suppose I'm writing a backend for a target which has an instruction that traps on any kind of NaN. Assuming I care about NaNs, I can't use such an instruction for regular floating-point operations. However, would it be ok to use it when the N flag is set?
> 
> 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.

> Dan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121101/45a2d48d/attachment.html>