similar to: [LLVMdev] sqrt

On Jan 7, 2010, at 7:06 AM, Jon Harrop wrote: > > What is the state of sqrt in LLVM? > > It was an intrinsic but there are no OCaml bindings for it and, last > I looked, > it generated inefficient code on Linux due to this bug: > > http://www.llvm.org/PR3219 > > Is the intrinsic deprecated? Am I losing a lot of performance by > calling sqrt > from libm

On Jan 7, 2010, at 11:48 AM, Chris Lattner <clattner at apple.com> wrote: > There is a fundamental difference between sqrt() and llvm.sqrt: the > former is defined on negative values and sets errno (on linux). The > later is undefined. Both work well for their stated purpose, > llvm.sqrt should not be slower than sqrt even on linux. Both > llvm.sqrt and sqrt could be much

On Jan 7, 2010, at 3:53 PM, Robert A. Zeh wrote: > > On Jan 7, 2010, at 11:48 AM, Chris Lattner <clattner at apple.com> wrote: > >> There is a fundamental difference between sqrt() and llvm.sqrt: the >> former is defined on negative values and sets errno (on linux). The >> later is undefined. Both work well for their stated purpose, >> llvm.sqrt should

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

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

----- 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 > >>

----- 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

On Nov 11, 2013, at 10:44 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> "Unlike sqrt in libm, however, llvm.sqrt has undefined behavior for >> ..." >> >> to "... produces an undefined value", with a link back to >> ##undefined-values. > > I'm not sure that helps, because it will prevents sqrt + -fno-math-errno (a readnone sqrt)

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:

Hi All, I'm tring to use RSQRT instructions on follow case for ARM (now what using is sqrt): 1.0 / sqrt(x) The RSQRT instructions(VRSQRTE/VRSQRTS) are vector type, but above operation is scalar type. So a transformation must be done(transform sqrt pattern to rsqrt). I have completed a patch for this, but I made the transformation in the backend which will leads to additional

> 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,

On Tuesday 16 December 2008 01:03:36 Evan Cheng wrote: > FYI. http://leonardo-m.livejournal.com/73732.html > > If anyone is motivated, please file bugs for the losing cases. Also, > it might make sense to incorporate the tests into our nightly tester > test suite. FWIW, I just ported my ray tracer benchmark to C and found that llvm-gcc gives much worse performance than gcc on x86

Using the following example program #include <math.h> double f(double d){ return sqrt(d); } and compiling it with "clang -O3 ...", I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a sqrtsd instruction inline. It turns out that it could do exactly that, were it not for the fact that in the function

On May 17, 2013, at 3:33 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote: > Using the following example program > > #include <math.h> > > double f(double d){ > return sqrt(d); > } > > and compiling it with “clang –O3 …”, I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a

On Jan 7, 2010, at 4:04 PMPST, Chris Lattner wrote: > On Jan 7, 2010, at 3:53 PM, Robert A. Zeh wrote: > On Jan 7, 2010, at 11:48 AM, Chris Lattner <clattner at apple.com> wrote: >> >>> There is a fundamental difference between sqrt() and llvm.sqrt: the >>> former is defined on negative values and sets errno (on linux). The >>> later is undefined.

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.

FYI. http://leonardo-m.livejournal.com/73732.html If anyone is motivated, please file bugs for the losing cases. Also, it might make sense to incorporate the tests into our nightly tester test suite. Thanks, Evan

Hi, We have implemented the rsqrt instruction generation for X86 target architecture. We have introduced a flag -fp-rsqrt flag which controls the generatation of X86 rsqrt instruction generation. We have observed minor effects on precision due to rsqrt and hence has put these transformations under the mentioned flag. Note that -fp-rsqrt is only enabled with -enable-unsafe-fp-math flag presently.

Hi, Please find attached the modified patch and description. We have modified and retested the patch taking into consideration the comments and inputs provided earlier. Thanks & Regards, soham -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Thursday, November 15, 2012 12:59 PM To: Chakraborty, Soham Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev]

Someone is trying to work on HLVM with me but they're hitting a problem that we have not been able to resolve. Specifically, GCC seems to be performing some kind of sanity check for "stack smashing" and is calling abort because it is unhappy with something that the code is doing. However, I am not sure what and cannot reproduce the problem. The stack trace they have given me is: