search for: sinf

Hello, clang/llvm 4.0.0 generates invalid calls for builtin functions with -mfloat-abi=hard -ffast-math. Small example fail.c: // clang -O2 -target armv7a-none-none-eabi -mfloat-abi=hard -ffast-math -S fail.c -o - extern float sinf (float x); float sin1 (float x) {return (sinf (x));} generates code to pass the parameter in r0 and expect the result in r0. The same code without -ffast-math compiles correctly. It also works with -fno-builtin-sinf. (-O2 is not required to trigger the bug, but makes the resulting code easi...

On 22 March 2017 at 01:38, Friedman, Eli <efriedma at codeaurora.org> wrote: >> Small example fail.c: >> >> // clang -O2 -target armv7a-none-none-eabi -mfloat-abi=hard -ffast-math >> -S fail.c -o - >> extern float sinf (float x); >> float sin1 (float x) {return (sinf (x));} I changed your example slightly to make sure we're passing the arguments, otherwise 'sin1' just becomes 'b sinf', which is "correct" on both hard and soft float. extern float sinf (float x); float sin1...

...pecifically, these need to be lowered to some sort of runtime calls (no hardware has support for these) and llvm doesn't provide a standard runtime yet. Unless the codegen has a way to lower these, it seems strange to add them as intrinsics. IOW, if llvm.sin.v4f32 ends up being 4 calls to sinf, why not encode 4 calls to sinf in the bytecode? -Chris -- http://nondot.org/sabre/ http://llvm.org/

...due to cost model reasons. Additionally, When the loop pragma is used, the loop vectorizer will widen the math call using an intrinsic, but the resulting code is inefficient because the intrinsic is replaced with scalarized function calls. Please see the example below for a simple loop containing a sinf call. For demonstration purposes, the example was compiled for an xmm target, thus VF = 4 given the float type. Example: sinf.c #define N 1000 #pragma clang loop vectorize(enable) for (i = 0; i < N; i++) { array[i] = sinf((float)i); } Without the loop pragma the loop vectorizer's cost...

Hi, I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available) Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the standard library function. Therefore it makes sense to transform intrinsic calls to sin and cos. One problem with this is that clang does not genera...

...due to cost model reasons. Additionally, When the loop pragma is used, the loop vectorizer will widen the math call using an intrinsic, but the resulting code is inefficient because the intrinsic is replaced with scalarized function calls. Please see the example below for a simple loop containing a sinf call. For demonstration purposes, the example was compiled for an xmm target, thus VF = 4 given the float type. Example: sinf.c #define N 1000 #pragma clang loop vectorize(enable) for (i = 0; i < N; i++) { array[i] = sinf((float)i); } Without the loop pragma the loop vectorizer's cost...

...se > need to be lowered to some sort of runtime calls (no hardware has support > for these) and llvm doesn't provide a standard runtime yet. Unless the > codegen has a way to lower these, it seems strange to add them as > intrinsics. IOW, if llvm.sin.v4f32 ends up being 4 calls to sinf, why not > encode 4 calls to sinf in the bytecode? Some of the hardware that we target has extensive support for these. Granted that instead of overloading llvm.sin and others for my vectors it'd be nicer to just have llvm.sin that accepts arbitrary vectors but it's still useful. Of...

...m-ld -o hellosin.llvm hellosin.bc -lm > $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc > hello sin: 0.50 Only because the optimizer saw sin(constant) and folded it away. The entire program became 'print constant string'. There is certainly a bug calling sinf() from the interpreter but I don't know what it is yet. > The pthread problem remains after llvm-ld: > > $ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc > 0 lli 0x08796bf8 > Segmentation fault I don't expect this to work at all. Unlike the JIT, I d...

On 22/01/13 05:30, Redmond, Paul wrote: [...] > I'm looking at http://llvm.org/bugs/show_bug.cgi?id=13204 which involves converting calls to sin and cos to sincos (when available) > > Initially I thought about transforming calls to sinf/cosf to sincosf. However, I don't think this is a legal transformation given that a declaration for a function called sinf is not necessarily the standard library function. I've actually just dealt with this --- standard library calls, including sinf, *are* promoted to intrinsics if the co...

Hi Nick: Thanks for the response. You are right about sinf. I changed the constant to sscanf(argv[1], ...), and it gave me back 0 again. I also compared the disassembled code, and saw it was indeed the case. The primary reason I use interpreter is because I wish to do runtime checking on memory access pattern in multithreaded C programs. for example, if t...

Hi Nick: Thanks for pointing me to libffi. Recompile LLVM with libffi does solve the problem of printf. But it still has other problems: 1) sinf() returns 0 in the interpreter, but returns correct value in JIT (see hellosin.c) 2) calling pthread_create cause lli to crash in the interpreter mode, but no problem in JIT (see phello.c). My questions are: i) can I call any arbitrary external function in the interpreter? ii) how do I specify the...

...b/pthread.a to /lib/libpthread.so.0. Thanks Xu On Wed, Nov 18, 2009 at 12:02 AM, Xu Yang <yangx2000 at gmail.com> wrote: > Hi Nick: > > Thanks for pointing me to libffi. > Recompile LLVM with libffi does solve the problem of printf. > But it still has other problems: > 1) sinf() returns 0 in the interpreter, but returns correct value in JIT > (see hellosin.c) > 2) calling pthread_create cause lli to crash in the interpreter mode, but > no problem in JIT (see phello.c). > > My questions are: > i) can I call any arbitrary external function in the interpre...

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++ >&gt...

Hi all, We know that Hermite polynomial is for Gaussian, Laguerre polynomial for Exponential distribution, Legendre polynomial for uniform distribution, Jacobi polynomial for Beta distribution. Does anyone know which kind of polynomial deals with the log-normal, Student抯 t, Inverse gamma and Fisher抯 F distribution? Thank you in advance! David [[alternative HTML version deleted]]

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

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 > >> TargetLowering.cpp > >> > >> my question is: wouldn't it be beneficial to use intrinsics for > &g...

On Tue, Nov 27, 2007 at 10:50:03AM -0700, Jon Sargeant wrote: > > > Do you have plans to add other intrinsics? I'm curious as to why there > > > is an llvm.sin intrinsic and an llvm.cos intrinsic, but no llvm.atan > > > intrinsic. Why is there an llvm.pow intrinsic but no llvm.log > > > intrinsic? > > > > Intrinsics get added on demand.

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: wouldn't it be beneficial to use intrinsics for this? > for example a c/c++ > frontend (clang) could translate...

Timo Juhani Lindfors wrote: > Nick Lewycky<nicholas at mxc.ca> writes: >> The interpreter uses libffi to make external function calls. However, it >> needs to be detected at LLVM's compile time. If you're using the >> released packages, we disabled that because we were worried about users >> who don't have libffi installed. > > This seems to be

...avenchuk wrote: > Is it possible to use dynamic library (*.so *.dll) from bytecode? > If "yes" - how? dlopen? That's be one way. Also, most systems have shared libraries in /usr/lib and these routines are meant to be linked against and used. For example, on darwin, there sinf is resolved from a shared library, you declare it and call it, as normal. You should be able to use llvm-gcc to see the bytecode of such a use of a routine from a dynamic library. ?