similar to: [LLVMdev] llvm.sqrt intrinsic undefined behaviour

> On Oct 31, 2013, at 6:16 AM, Nicholas Chapman <admin at indigorenderer.com> wrote: > > I propose changing the llvm.sqrt() LLVM instrinsic to be well defined on all inputs, and be defined to return NaN on negative inputs. I strongly disagree with this proposal. The purpose of this general purpose intrinsic is to expose sqrt functionality present on many of the architectures LLVM

On Nov 11, 2013, at 9:30 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> Hi Hal, all. >> >> I'm not sure why llvm.sqrt is 'special'. Maybe because there is a >> SSE >> packed sqrt instruction (SQRTPS) but not e.g. a packed sin >> instruction >> AFAIK. > > This seems relevant:

----- Original Message ----- > Hi Hal, all. > > I'm not sure why llvm.sqrt is 'special'. Maybe because there is a > SSE > packed sqrt instruction (SQRTPS) but not e.g. a packed sin > instruction > AFAIK. This seems relevant: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-August/010248.html Chris, et al., does the decision on how to treat sqrt predate our

Hi Hal, all. I'm not sure why llvm.sqrt is 'special'. Maybe because there is a SSE packed sqrt instruction (SQRTPS) but not e.g. a packed sin instruction AFAIK. As mentioned in a recent mail to this list, I would like llvm.sqrt to be defined as NaN for argument x < 0. I believe this would bring it more into line with the other intrinsics, and with the libm result, which is

> I strongly disagree with this proposal. The purpose of this general > purpose intrinsic is to expose sqrt functionality present on many of > the architectures LLVM supports. If we defined its edge cases, we > won't be able to map it to target functionality freely on targets whose > edge cases don't match that definition. I agree the targets should be the primary focus,

Hello everyone, The particular motivation for this e-mail is my desire for feedback on how to fix PR17758; but there is a core design issue here, so I'd like a wide audience. The underlying issue is that, because the semantics of llvm.sqrt are purposefully defined to be different from libm sqrt (unlike all of the other llvm.<libm function> intrinsics) (*), and because autovectorization

----- Original Message ----- > > On Nov 11, 2013, at 9:30 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ----- Original Message ----- > >> Hi Hal, all. > >> > >> I'm not sure why llvm.sqrt is 'special'. Maybe because there is a > >> SSE > >> packed sqrt instruction (SQRTPS) but not e.g. a packed sin > >>

In llvm.sqrt, why is the penalty for negative operands undefined behavior, as opposed to merely an unspecified result? As an example, in code like this: %x = call float @llvm.sqrt.f32(float %y) %z = fcmp oge float %y, -0.0 Does LLVM intend to reserve the right to assume that %z is always true? Or that %z is undef? Or even that any statement dominated by %x is unreachable? There's the

My colleague Will Schmidt recently discovered (http://llvm.org/bugs/show_bug.cgi?id=21048) that the LLVM optimizers are converting sqrt(n), where n is negative, into 0.0. Now, as Sanjay pointed out, the value of sqrt(n) for negative n other than -0.0 is undefined according to the C99 standard, so this is allowable behavior. But I think that it's not necessarily good behavior, nonetheless.

That's a pretty seriously unsafe floating point optimization. It could be done in fast-math mode, but I doubt we currently do it. --Owen On Apr 23, 2013, at 1:12 PM, Erkki Lindpere <villane at gmail.com> wrote: > hi! > > I'm using LLVM 3.2. Does it optimize away llvm.pow(llvm.sqrt(x), 2) to `x` with any settings? I tried with llc -O3, but that didn't do it. >

hi! I'm using LLVM 3.2. Does it optimize away llvm.pow(llvm.sqrt(x), 2) to `x` with any settings? I tried with llc -O3, but that didn't do it. Would be nice to write |v|² in my language ('v' being a 2D vector say and |...| and ...² being two separate infix "operators") -- when I could compare squares of lengths as well as lengths, and know that the sqrt is optimized

On Fri, 2014-09-26 at 13:36 -0500, Hal Finkel wrote: > ----- Original Message ----- > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > To: "Stephen Canon" <scanon at apple.com> > > Cc: spatel+llvm at rotateright.com, "Will Schmidt" <will_schmidt at vnet.ibm.com>, "LLVM Developers Mailing List" > >

On Fri, 2014-09-26 at 12:09 -0400, Stephen Canon wrote: > > On Sep 26, 2014, at 11:59 AM, Tim Northover <t.p.northover at gmail.com> wrote: > > > >> I know it's part of test-suite/external, but this constant fold code has > >> been around 5+ years. Was the bug lying dormant all this time, only visible > >> on PPC, or something else? > > >

This isn't purely a fast-math issue...ConstantFolding isn't using enable-unsafe-fp-math to decide whether to emit the '0'. It's just looking for the llvm intrinsic rather than a call to sqrt: %0 = call double @llvm.sqrt.f64(double -2.000000e+00) vs: %0 = call double @sqrt(double -2.000000e+00) #2 So how about a front-end fix: If the parameter is a negative constant,

I want to create a vector version sqrt as the following. Value *Approx::CreateFSqrt(IRBuilder<> &builder, Value *v, const char* Name) { Type *tys[] = {v->getType()}; Module* M = currF->getParent(); Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd); CallInst *CI = builder.CreateCall(sqrtv, v, Name); return CI; } Here is Value *v is <2 x

Thanks, Shahid. It is fixed now. On Fri, Apr 17, 2015 at 8:50 PM, Shahid, Asghar-ahmad < Asghar-ahmad.Shahid at amd.com> wrote: > Hi zhi, > > > > You have to also pass the value type to getDecalaration() API such as > > > > Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd, > v->getType()); > > > > Regards, > >

Hi Everyone, I did a search through the archives and did not find an answer, although I must admit it is a hard search to do ( ^0.5 is tough to explicitly search for ). I am sure there is some mathematically accurate reason to explain the following, but I guess I either never learned it or have since forgotten it. In 'R', when I type (for instance): sqrt(-4) I get NaN

> I know it's part of test-suite/external, but this constant fold code has > been around 5+ years. Was the bug lying dormant all this time, only visible > on PPC, or something else? My guess would be that people don't tend to run with -ffast-math (it's got a reputation for breaking code, even ignoring this particular issue). Without that, from what I can see the issue

Am Dienstag, 23. April 2013, 22:50:51 schrieben Sie: > [...] > Giving more-than-expected precision can be just as bad for the user as less. > It tends to come up in situations where the optimization would break some > symmetry, the same way that aggressively forming FMAs can break user code. > [...] > > It boils down to the fact that giving excess precision in >

Hi Evan, all, The most obvious thing to me would be to extend the load instruction to have an additional form that takes a vector of pointers instead of a single pointer. This form would return a vector of values instead of a single value. If a gather instruction is not available on the target, then the load could be lowered to a series of scalar loads and insertelements. Thanks, Nick On