similar to: [LLVMdev] Generate assembly without sqrt.d

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

Hi! in the llvm code there are several places with hardcoded function names for e.g. sin, sinf, sqrt, sqrtf etc., namely ConstantFolding.cpp InlineCost.cpp SelectionDAGBuilder.cpp IntrinsicLowering.cpp TargetLowering.cpp my question is: wouldn't it be beneficial to use intrinsics for this? for example a c/c++ frontend (clang) could translate the function calls to intrinsics and then in a

Hi, >> in the llvm code there are several places with hardcoded function >> names for e.g. sin, sinf, sqrt, sqrtf etc., namely >> ConstantFolding.cpp >> InlineCost.cpp >> SelectionDAGBuilder.cpp >> IntrinsicLowering.cpp >> TargetLowering.cpp >> >> my question is: wouldn't it be beneficial to use intrinsics for this? >> for example a

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully

On Fri, 02 Mar 2012 13:55:18 +0100 Jochen Wilhelmy <jochen.wilhelmy at googlemail.com> wrote: > Hi! > > in the llvm code there are several places with hardcoded function > names for e.g. sin, sinf, sqrt, sqrtf etc., namely > ConstantFolding.cpp > InlineCost.cpp > SelectionDAGBuilder.cpp > IntrinsicLowering.cpp > TargetLowering.cpp > > my question is:

sqrtf is detected by code in SelectionDAGBuilder.cpp. This gets turns into a FSQRT ISD node type that the target can handle just like any other ISD node. If the target doesn't mark ISD::FSQRT as Legal or Custom then ExpandNode in LegalizeDAG.cpp turns it back into a sqrtf libcall. On Sun, Jan 20, 2013 at 11:34 AM, David Given <dg at cowlark.com> wrote: > On 20/01/13 19:20,

On Fri, 02 Mar 2012 16:05:17 +0100 Duncan Sands <baldrick at free.fr> wrote: > Hi, > > >> in the llvm code there are several places with hardcoded function > >> names for e.g. sin, sinf, sqrt, sqrtf etc., namely > >> ConstantFolding.cpp > >> InlineCost.cpp > >> SelectionDAGBuilder.cpp > >> IntrinsicLowering.cpp > >>

We've got both an sqrtf and an expf opcode in our architecture. If I call sqrt() on the C side, I see the sqrtf opcode show up in the generated assembly. However, if I call exp() on the C side, I don't see the expf opcode show up on the generated assembly, I see a call to an exp function from libm. Here's what we've got in our TargetInstrinfo.td file for both of these

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

Hi Micheal, Thanks for the blog post. Just like to point out few things that I thought is related to FP Numerics. LLVM could do some additional transformation with "sqrt" and "division" under fast math on X86 like 1/sqrt(x)* 1/sqrt(x) to 1/x. These are long latency instructions and could get benefit if enabled under unsafe math. Also are we considering doing such FP

Hi I'm having a problem compiling opus-tools-0.1.7. Version opus-tools-0.1.6 seems to compile OK. I've tried with opus-1.0.3 and opus-1.1-beta. The errors are like this:- "undefined reference to `sqrtf'" etc. This OS is Peppermint Three, similar to Ubuntu 12.04. It uses:- gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Google says it's maybe something to do

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

This is in response to NO_FLOAT_MATH_LIB not getting set on Solaris. The patchlet below - makes configure check for sqrtf(), - defines HAVE_SQRTF if sqrtf() has been found, - uses HAVE_SQRTF in lib/os.h. NO_FLOAT_MATH_LIB isn't used any longer. --- configure.in.orig Fri Mar 30 02:02:35 2001 +++ configure.in Fri Mar 30 02:10:16 2001 @@ -162,6 +162,7 @@ dnl

Does fast-math imply no-math-errno ? Thanks, Nadav On May 17, 2013, at 15:36, Chris Lattner <clattner at apple.com> wrote: > > 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);

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:

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)

Hello, I am trying to cross-compile libc++ from my x86_64 linux system to armv7hf. We have our own gcc compiler that we build with crosstools-ng (based on gcc 6.3.0) and I set my environment like this: CC=armv7a-plex-linux-gnueabihf-gcc CXX=armv7a-plex-linux-gnueabihf-g++ CFLAGS=-fPIC -DPIC -mfloat-abi=hard -march=armv7-a -Os -mfpu=vfpv3-d16 --sysroot=<path> CXXFLAGS=-fPIC -DPIC

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

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