similar to: PR43374 - when should comparing NaN values raise a floating point exception?

* Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> [2019-10-01 09:44:54 -0400]: > Let's change the example to eliminate suspects: > #include <math.h> > int is_nan(float x) { > /* > The following subclauses provide macros that are quiet (non > floating-point exception raising) > versions of the relational operators, and other comparison

Ulrich offered to do it instead since I expect he can get it done much faster than me. Instead I'm doing SIToFP and UIToFP. Ulrich said he wasn't going to be able to get to it for a couple of weeks, but that was a week or two ago. Ulrich? -----Original Message----- From: Cameron McInally <cameron.mcinally at nyu.edu> Sent: Tuesday, October 01, 2019 10:21 AM To: Kristof Beyls

On Wed, Feb 4, 2015 at 11:24 AM, John Regehr <regehr at cs.utah.edu> wrote: > I am actively working towards removing poison altogether. I think a more >> accurate model of LLVM's wrapping >> flags is not poison but instead something akin to the fast-math flags on >> floating point instructions. >> > > Looking forward to seeing it. One of my students has

On Wed, Feb 4, 2015 at 9:13 AM, John Regehr <regehr at cs.utah.edu> wrote: > I think such a thing would be great. However, there is a problem that the >> RFC wasn't aware of when it was >> written: >> >> consider: >> %S = select %A, %B, undef >> >> without us knowing anything about %A or %B, we will replace all uses of >> %S with %B.

* Sanjay Patel <spatel at rotateright.com> [2019-10-08 08:07:10 -0400]: > On Tue, Oct 8, 2019 at 7:08 AM Szabolcs Nagy <nsz at port70.net> wrote: > > why is that ok? > > > > Because there are no FP exceptions/signals for this IR opcode: > http://llvm.org/docs/LangRef.html#floating-point-environment so llvm cannot support an iso c frontend on an ieee754 target?

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmp_IntToFP_Cst, there are these lines: // Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero) return nullptr; Why check for positive

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,

Yes, the modeling of floating-point is trickier. The wrap-around trick used by ConstantRange seems less applicable, and there are the unordered NaNs. Though in all cases, the key abstraction is a lattice of values, so an instance of FPRange should be thought of as a point on a lattice, not an interval. The lattice needs to be complicated enough the cover the cases of interest, but not so

Thanks for checking this out. I think your second comment on 35538 must be precisely what I'm talking about. I came up with this IR that might be used for testing: ``` define float @minloop(float* nocapture readonly) #0 { top: %1 = load float, float* %0 br label %loop loop: %2 = phi i64 [ %8, %loop ], [ 1, %top ] %3 = phi float [ %7, %loop ], [ %1, %top ] %4 = getelementptr

On Wednesday, December 05, 2012 at 2:48 PM, Chris Lattner wrote: > > What does the community think? > > It seems inevitable. For the floating point version, please make it very 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.

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

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]

Thanks for the reply. I should say I'm actually working on 6.0, but I don't think this part of the code changed much since. These are traces I made with GDB optimizing a loop with floats and then integers, showing where they diverge: https://gist.github.com/nlw0/58ed9fda8e8944a9cb5e5a20f6038fcf This is the point I believe we need to set the function attribute for the vectorization to work

Both ZF and PF will be set if unordered, so the code below is IEEE correct...you want to generate 'fcmp ueq' instead of 'fcmp oqe' This is the resulting x86 assembly code: movss xmm0,dword ptr [ecx+4] ucomiss xmm0,dword ptr [ecx+8] sete al setnp dl test dl,al mov edx,edi cmovne edx,ecx cmovne ecx,esi cmovne

Note: Question is written after describing what I have coded. Hello LLVMDevs, I am trying to impliment floating point comparsion for an architecture which supports following type of floating point comparision if FPU is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN

Greetings, The LLVM loop vectorizer does a great job handling reductions with the `min(a, b)` function over an array of integers or floats. This finds the smallest value of a list exploiting SIMD instructions, and works just as well as a summation. Specifically with floats, though, using the `fcmp` instruction, the vectorization seems to require the function attribute "no-nans-fp-math"

On Thu, Mar 9, 2017 at 9:35 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 02/25/2017 03:06 AM, vivek pandya via llvm-dev wrote: > > Note: Question is written after describing what I have coded. > > Hello LLVMDevs, > > I am trying to impliment floating point comparsion for an architecture > which > supports following type of floating point comparision if FPU

On 03/14/2017 07:16 AM, vivek pandya wrote: > Hello Hal, > setCondCodeAction(expand) for un ordered comparison generates > semantically wrong code for me for example SETUNE gets converted to > SETOE that causes infinite loops. Can you please explain what is happening? It sounds like a bug we should fix. > > What is ideal place where I can convert unordered comparison to un

Hi, I’d like to re-propose adding intrinsics for fmin / fmax. These can be used to implement the equivalent libm functions as defined in C99 and OpenCL, which R600 and AArch64 at least have instructions with the same semantics. This is not equivalent to a simple fcmp + select due to its handling of NaNs. This has been proposed before, but never delivered

On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote: > Hi Nick, > >> Now that icmp and fcmp have supported returning vectors of i1 for a >> while, > > the code generators don't know how to codegen vectors of i1, so does > this actually work? No, but there are no clients of them yet. -Chris