similar to: [LLVMdev] Compiling LLVM on MinGW

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

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

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

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

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

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 mentioned on his blog that he got substantial performance improvements by conveying to LLVM when external functions (e.g. tanh) were pure. How is this done? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

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

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,

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

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

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

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

Hi, > On Mon, Oct 12, 2009 at 1:07 PM, David Greene <dag at cray.com> wrote: >> Are there any implicit assumptions about where alloca instructions >> can appear. > > Static allocas should appear as a continuous chunk in the entry block, > otherwise other passes might make bad assumptions. an alloca can appear anywhere, but when they are outside the entry block then

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). On Tue, Oct 13, 2009 at 9:44 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > >> On Mon, Oct 12, 2009

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

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

Hi all, Five minutes ago I heard a rumor that Lennart Poettering has rewritten rsync. My top urgency is to download the latest numbered version of rsync untouched by Lennart Poettering: I'll find out if the rumor is true or false later. I've downloaded rsync rsync-3.1.3.tar.gz and rsync-patches-3.1.3.tar.gz from https://download.samba.org/pub/rsync/ . Is the source code in both those