search for: qnan

...greed.  Those IR instructions are undefined on SNAN, and that undef > could take on an SNAN value.  Folding these instructions to undef > seems reasonable, and it is arguable that you could even fold it to an > ‘unreachable'. fdiv snan, snan is undefined?  As opposed to producing a qnan, as specified by IEEE-754? -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/...

...t;> Agreed. Those IR instructions are undefined on SNAN, and that undef could take on an SNAN value. Folding these instructions to undef seems reasonable, and it is arguable that you could even fold it to an ‘unreachable'. > > fdiv snan, snan is undefined? As opposed to producing a qnan, as specified by IEEE-754? You’re talking about IEEE, I’m talking about LLVM IR. LLVM IR is undefined on SNaNs. It looks like LangRef isn’t clear about this, the only mention of SNaNs is in this statement: "fdiv is not (currently) defined on SNaN’s.” However, fdiv/fmul/etc are pervasive...

...reading of IEEE 754-2008 is that floating-point comparison operations cannot distinguish a negative zero from a positive zero. Further supporting this is that fact that http://llvm.org/docs/LangRef.html describes the difference between "ordered" and "unordered" as pertaining to QNAN operands, with no mention of negative zero. I tried fixing the issue, but then the following test in cast-int-fcmp-eq-0.ll fails: ; CHECK-LABEL: @i32_cast_cmp_oeq_int_n0_uitofp( ; CHECK: uitofp ; CHECK: fcmp oeq define i1 @i32_cast_cmp_oeq_int_n0_uitofp(i32 %i) { %f = uitofp i32 %i to float %...

...9;t a problem for most test-suite runs since we can just update the assembler but is causing trouble for microMIPS. More recent toolchains lack the microMIPS multilib I was using and migrating to the new one is causing link failures. These failures are related to ELF header bits specifying the SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the -mnan=2008 isn't reaching the assembler. 3. Clang is incompatible with changes to the mips-mti-linux-gnu sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries are still multilib'd (albeit with a red...

...e way R is written. Does anyone know for certain which it might be? If it is a bug in the Zaurus' fp implementation then I don't see any real troubles getting it fixed (I'm sure people will be keen to get this right). I notice that there are two types of NaNs in the ieee 754 standard, QNaN (Quiet NaN) and SNaN (Signalling NaN). Does 8.29488e-311 look familiar (I didn't think so)? Regards, Simon -------------------------------------------- Simon Pickering MEng Dept. of Mechanical Engineering University of Bath Bath, BA2 7AY, UK Tel: +44 (0)1225 383314 Fax: +44 (0)1225 386928...

...!=x does. > > As IR from clang with no optimization, this becomes a bunch of load/store > with: > %cmp = fcmp uno double %conv, %conv1 > > Ok, so far? "fcmp uno" - http://llvm.org/docs/LangRef.html#fcmp-instruction > : > uno: yields true if either operand is a QNAN. why is that ok? here you need an unordered-not-equal, but got an unordered-compare, the former is a silent ieee754 operation the latter is signaling. as noted earlier this is wrong for signaling nans, because any fcmp would signal for them, but the lack of snan support can be forgiven, however...

...> ideally there would be a way to support snan too. (e.g. isnan(x) cannot be turned into x!=x then) The except_behavior mode is supposed to handle this. The LLVM support for constrained intrinsics is considering all manner of FP exceptions that could be raised, including the distinction between QNaN and SNaN. The default LLVM IR definition does not support this distinction. We seem to have an issue with isnan() in clang though. If you call isnan() you get a call to __isnan() which should be fine (assuming the library does the right thing), but we're translating __builtin_isnan() to x!=x....

...st test-suite runs since we can just update the > assembler but is causing trouble for microMIPS. More recent toolchains lack > the microMIPS multilib I was using and migrating to the new one is causing > link failures. These failures are related to ELF header bits specifying the > SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect > the –mnan=2008 isn't reaching the assembler. > > 3. Clang is incompatible with changes to the mips-mti-linux-gnu > sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries are still > multilib&...

...9;t a problem for most test-suite runs since we can just update the assembler but is causing trouble for microMIPS. More recent toolchains lack the microMIPS multilib I was using and migrating to the new one is causing link failures. These failures are related to ELF header bits specifying the SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the –mnan=2008 isn't reaching the assembler. 3. Clang is incompatible with changes to the mips-mti-linux-gnu sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries are still multilib'd (albeit with a red...

...we can just update the > > assembler but is causing trouble for microMIPS. More recent toolchains > lack > > the microMIPS multilib I was using and migrating to the new one is causing > > link failures. These failures are related to ELF header bits specifying the > > SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I > suspect > > the –mnan=2008 isn't reaching the assembler. > > > > 3. Clang is incompatible with changes to the mips-mti-linux-gnu > > sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries...

...il.list at gmail.com> wrote: > > Hi Duncan, > > I reread everything we've discussed so far and would like to pay closer attention to the the ARM's FPSCR register mentioned by Stephen. > It's really possible on ARM systems that floating point operations on one or more qNaN operands return a NaN different from the operands. I.e. operand NaN is not propagated. This happens when the "default NaN" flag is set in the FPSCR (floating point status and control register). The result in this case is some default NaN value. > > This means "fadd %x, -0.0&qu...

Hi Oleg, On 01/09/14 18:46, Oleg Ranevskyy wrote: > Hi Duncan, > > I looked through the IEEE standard and here is what I found: > > *6.2 Operations with NaNs* > /"For an operation with quiet NaN inputs, other than maximum and minimum > operations, if a floating-point result is to be delivered the result shall be a > quiet NaN which should be one of the input

So you don’t think sNaNs can just be treated as if they were qNaNs? I understand why we would want to ignore the signaling part of things, but the rules for operating on NaNs are pretty clear and reasonable to implement. The signaling aspect can, I think, be safely ignored when we are in the mode of assuming the default FP environment. As for the distinction bet...

On Feb 28, 2018, at 3:29 PM, Kaylor, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” Agreed. Those IR instructions are undefined on SNAN, and that undef could take on an SNAN value. Folding these instructions to undef seems reasonable, and it is arguable

I am having a little trouble with the fcmp one instruction on doubles only. For ordered comparisons, the LLVM manual states that true should be returned iff neither operands is QNAN. ( http://llvm.org/docs/LangRef.html#i_fcmp) If I do fcmp one which includes one or both operands as a NaN, the result is expected to be 0 then. If I run the bitcode with lli (JIT off), no problem. If I use the JIT (lli --force-interpreted=true), then it returns 1. (Converely, fcmp une with th...

...ery clear > what the behavior of max(-0,+0) and related cases are. The following is our current proposal for llvm.fmax/fmin.*: [1] If exactly one argument is a NaN, the intrinsic returns the other argument. [2] If both arguments are NaN, the intrinsic returns a NaN. [3] An SNaN may behave as a QNaN. [4] If the arguments compare equal, the intrinsic returns a value that compares equal to both arguments. [5] Otherwise, the intrinsic returns the greater/lesser of the two arguments. Rationale and notes: Points [1] and [2] match the C/Posix library functions' specs. Point [3] matches the Op...

Maybe we can have two versions of the intrinsic function, "ordered" and "unordered", just like fcmp has [1]. Would that work ? [1] - http://llvm.org/docs/LangRef.html#fcmp-instruction On Dec 17, 2012, at 11:14 AM, "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> wrote: > At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com]

...9;t a problem for most test-suite runs since we can just update the assembler but is causing trouble for microMIPS. More recent toolchains lack the microMIPS multilib I was using and migrating to the new one is causing link failures. These failures are related to ELF header bits specifying the SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the –mnan=2008 isn't reaching the assembler. > > 3. Clang is incompatible with changes to the mips-mti-linux-gnu sysroot from Imagination's mips-mti-linux-gnu toolchain. Libaries are still multilib'd (albeit...

At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: >This part worries me. The new min/max intrinsics will only be useful if we could pattern match cmp/select into them. Yes, that's the obvious alternative. I don't think we have any strong opinion either way, and fcmp/select is certainly easier to implement. -- Kevin Schoedel, Software Developer,

On Dec 5, 2012, at 8:26 AM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > I have been working on a patch to add support for max/min reductions in LoopVectorize. One of the comments that came up in review is that the implementation could be simplified (and less fragile) if max and min intrinsics were recognized rather than looking for compare-select sequences. > >