similar to: [LLVMdev] Pure external functions

On Tuesday 17 February 2009 09:46:07 Duncan Sands wrote: > Hi, > > > Lennart Augustsson mentioned on his blog that he got substantial > > performance improvements by conveying to LLVM when external functions > > (e.g. tanh) were pure. > > first note that tanh is not pure, because the result depends on the current > floating point rounding mode. Ugh. > However,

Hi, > Lennart Augustsson mentioned on his blog that he got substantial performance > improvements by conveying to LLVM when external functions (e.g. tanh) were > pure. first note that tanh is not pure, because the result depends on the current floating point rounding mode. However, if you are willing to sacrifice complete numerical correctness, you can give llvm-gcc the -ffast-math

I'm using configure. On Mon, Mar 9, 2009 at 5:12 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Lennart Augustsson <lennart at augustsson.net> writes: > >> Commenting out the Hello transformation I get these link errors: >> >> llvm[2]: Linking Debug Shared Library LTO.dll >>

Jon Harrop wrote: > If you are familiar with functional programming and, in particular, its > benefits in the context of compiler work then you might like to use Gordon's > OCaml bindings to LLVM that are bundled with LLVM. They are very easy to use > and will make subsequent work vastly easier than trying to write everything > in C++. Or, indeed, the Haskell bindings

On Jan 24, 2009, at 4:34 AM, Lennart Augustsson <lennart at augustsson.net> wrote: > Hi, > > Is there some documentation about what has not been implemented yet? I've started adding notes to docs/LangRef.html Historically this document has been used to describe just the LLVM IR, and not what specific consumers of it do or don't support, but codegen is a very

Lennart Augustsson <lennart at augustsson.net> writes: > Commenting out the Hello transformation I get these link errors: > > llvm[2]: Linking Debug Shared Library LTO.dll > c:/DOCUME~1/1312888/Desktop/Workspace/llvm/llvm-top/Debug/lib/libLLVMSystem.a(Signals.o): > In function `Z28LLVMUnhandledExceptionFilterP19_EXCEPTION_POINTERS': >

Commenting out the Hello transformation I get these link errors: llvm[2]: Linking Debug Shared Library LTO.dll c:/DOCUME~1/1312888/Desktop/Workspace/llvm/llvm-top/Debug/lib/libLLVMSystem.a(Signals.o): In function `Z28LLVMUnhandledExceptionFilterP19_EXCEPTION_POINTERS': c:/DOCUME~1/1312888/Desktop/Workspace/llvm/llvm-top/lib/System/Win32/Signals.inc:164: undefined reference to

Hi, Is there some documentation about what has not been implemented yet? I'm trying to use vectors and I just run into one thing after another that seem to be missing. (I.e., fcmp on vectors doesn't work; trying to do the same thing with expanded instructions doesn't work; select on a vector doesn't work) -- Lennart

Like this: llvm[1]: Compiling Signals.cpp for Debug build In file included from Signals.cpp:33: Win32/Signals.inc:262: error: `sys' has not been declared Win32/Signals.inc: In function `void AddSignalHandler(void (*)(void*), void*)': Win32/Signals.inc:266: error: `KillSigs' was not declared in this scope Win32/Signals.inc:266: error: `KillSigsEnd' was not declared in this scope

On Sunday 08 March 2009 01:42:42 Lennart Augustsson wrote: > I'm trying to compile the top version of LLVM with MinGW, but I'm > getting compilation errors. What kind of errors? Ciao, Duncan.

On Mar 8, 2009, at 4:21 AM, Lennart Augustsson wrote: > Like this: > > llvm[1]: Compiling Signals.cpp for Debug build > In file included from Signals.cpp:33: > Win32/Signals.inc:262: error: `sys' has not been declared > Win32/Signals.inc: In function `void AddSignalHandler(void (*) > (void*), void*)': > Win32/Signals.inc:266: error: `KillSigs' was not declared

On Tuesday 13 October 2009 04:02, Lennart Augustsson wrote: > And you really want your allocas in the entry block so they are > implemented by just stack pointer manipulation rather than calling > alloca(). The latter is slower, and there's also a bug that makes > calling alloca() not getting the alignment right (if it's > 8). Is there a bug number for that? I wonder if

On Tuesday 05 February 2008 12:40:20 thomas weidner wrote: > I wanted to roll out my own lisp, and maybe use some library code from > existing lisps (think of loop or format). Adding an LLVM backend to an > existing lisp implementation is a nice idea, but currently not planned. I am also interested in implementing functional programming languages using LLVM. Although I'm only

I'm trying to compile the top version of LLVM with MinGW, but I'm getting compilation errors. They seem to be caused by the changes in rev 66072. Has anyone compiled on MinGW? Since I just installed MinGW on this computer it could be my problem. (I noticed that LLVM 2.5 still doesn't come with binaries for the libraries on MinGW.) -- Lennarft

Are there any imminent plans to extend the C API to make it more complete? Or should I just make a bug report with patches for the calls that I need that are missing? -- Lennart

Is there a guide anywhere to embedding LLVM into a program to compile and run a DSEL? Thanks, Sean

For future reference: https://sourceforge.net/p/mingw-w64/mailman/message/35747206/ On Wed, Mar 22, 2017 at 2:12 PM, Jeroen Ooms <jeroenooms at gmail.com> wrote: > This looks like a bug in mingw-w64 CRT. The problem can be produced > with C++ without R: > > #include <iostream> > #include <cmath> > #include <complex> > > int main(){ >

For a while I have been getting that the complex tests fails on RHEL 6. The specific issue has to do with tanh (see below for full output from complex.Rout.fail). This is both with the stock compiler (GCC 4.4.7) and a compiler supplied through the conda project (GCC 4.8.5). The compiler supplied through conda ends up linking R to certain system files, so the binary is not completely independent

Scott Michel <scottm <at> rushg.aero.org> writes: > Out of curiousity, for which CL implementation is this targeted? sbcl? > Or something you're rolling? I wanted to roll out my own lisp, and maybe use some library code from existing lisps (think of loop or format). Adding an LLVM backend to an existing lisp implementation is a nice idea, but currently not planned. >

Thanks. I assume there is no way to control this via. environment variables or configure settings? Obviously that would be great for something like this which affects tests and seems to be a known problem for older C standard libraries. Best, Kasper On Thu, May 4, 2017 at 9:12 AM, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > As a quick fix, you can undefine HAVE_CTANH