similar to: [LLVMdev] Extending LLVM

Hi all, I just wanted to know if anyone's looked into using the free version of Microsoft's Visual C++ toolkit for LLVM: http://msdn.microsoft.com/visualc/vctoolkit2003/ -bw -- || "If wishes and buts were clusters of nuts, we'd all have a bowl of || granola!" - Mr. Jellineck

On Fri, 26 Mar 2004, Bill Wendling wrote: > It is possible to extend LLVM to add, say, matrix operations at a higher > level and then "lower" them into some version of LLVM "proper" after > performing any transformations on them, right? Also, it's possible to > have any custom-made types (like "matrix") as well? It is certainly possible to do things

Hi all, Quick question: What is the best way to have multiple return values from a function? Would that be placing these into a structure and returning that to the caller? Thanks. -bw -- || "If wishes and buts were clusters of nuts, we'd all have a bowl of || granola!" - Mr. Jellineck

Chris Lattner wrote: } > I tend to agree. I'm a strong advocate of XML myself (on other } > projects). However, introducing XML would make LLVM dependent on some } > kind of XML parser. We could probably get away with expat (small, fast) } > for our purposes in LLVM, but there is still the issue of dependency. To } } To me, it's not a matter of "one more

Henrik Bach wrote: } Hi John, } } configure still exits, when checking for uint64_t. I've attached a patch, } that properly will fix it. Either uint64_t or u_int64_t will succeed: } } Index: configure.ac } =================================================================== } RCS file: /var/cvs/llvm/llvm/autoconf/configure.ac,v } retrieving revision 1.106 } diff -u -r1.106 configure.ac } ---

Hi Reid, > Since there's been little feedback on the design document I sent out, > some decisions are being made in order to progress the work. If you have > strong feelings about any of these, voice them now! > > 1. Name = llvmcc I like llvmcc, but really have no strong opinion. > 2. The config file format will resemble Microsoft .ini files > (name=value in

Hi all, I get this warning during compilation: make[3]: Entering directory `/home/wendling/llvm/llvm/lib/ExecutionEngine/JIT' Compiling Emitter.cpp Emitter.cpp:44:1: warning: "_POSIX_MAPPED_FILES" redefined In file included from /usr/include/unistd.h:171, from /usr/include/c++/3.3.1/i586-mandrake-linux-gnu/bits/gthr-default.h:38, from

On Mon, 2 Aug 2004, Reid Spencer wrote: > Hi Bill, > On Mon, 2004-08-02 at 21:31, Bill Wendling wrote: > > Hi Reid, > > > > > Since there's been little feedback on the design document I sent out, > > > some decisions are being made in order to progress the work. If you have > > > strong feelings about any of these, voice them now! > > >

Hi John, configure still exits, when checking for uint64_t. I've attached a patch, that properly will fix it. Either uint64_t or u_int64_t will succeed: Index: configure.ac =================================================================== RCS file: /var/cvs/llvm/llvm/autoconf/configure.ac,v retrieving revision 1.106 diff -u -r1.106 configure.ac --- configure.ac 2 Sep 2004 18:44:44 -0000

I was going to wait to bring this up but since the topic has been addressed ... Would people other than myself find it useful to have a standardized extension framework for LLVM? I'm thinking of something that would allow new LLVM instructions, fundamental types, structured types, etc. This would require significant work to allow the various pieces of LLVM (assembler, disassembler, runtime,

LLVM Developers, We've added a page to the main web site that provides links to each LLVM Developer's home page and/or personal LLVM Notes page. You can find it here: http://llvm.org/Developers.html or just click the link titled "LLVM People" on the left of the main page. The list isn't complete but contains pictures and links for everyone that responded in IRC this morning

Hello, is there any documentation for LLVM codebase other than produced by doxygen? The reason I'm asking is that doxygen docs are (1) not very complete at the moment, as lot of classes don't even have a description (2) is generally not the best way to get high-level view of a big codebase. As an example, consider this code: %tmp.1 = setgt int %i, 0 br bool %tmp.1, label

An Investor ALERT is being issued starting right N0W. Keep your eyes glued on PSUD!! Explosive pick for our members! PETROSUN DRILLING (PSUD) Current Price: 1.13 Don't get caught in the dust, start watchin today because this company has been known to release major news at any time which could bring the st0ck up!! Current News PetroSun Named Title Sponsor of The Independence Bowl

I would also find this extension framework useful. Particularly, I would like to add intrinsics (without checking them into the LLVM source), and an "opaque" instruction which does not write to memory (and hence can be DCEliminated). Just a thought... Rahul ---- Original message ---- >Date: Fri, 26 Mar 2004 14:41:17 -0800 >From: Reid Spencer <reid at x10sys.com>

the data file has such structure: 1992 6245 49 . . 20 1 0 0 8.739536 0 . . . . . . . . "alabama" . 0 . 1993 7677 58 . . 15 1 0 0

I got a message from the organizer, for the first time the video feed of the Golden Penguin Bowl is available.... So if you never saw me making a complete fool of myself live, now's your chance to see it second hand :-) :-). John Mark Walker wrote : > Hey ho... so the Golden Penguin Bowl video is now up, and you can get to > it from http://www.linuxworldblog.com/ Jeremy.

Duncan Sands wrote: >> As noted in the GEP FAQ, GEPs don't support variable-length arrays; > > that's not quite right. The problem is only with arrays of variable length > arrays, and more generally with arrays where the element type has variable > size (this occurs with Ada, which has all kinds of funky variable sized types, > for example). You're right, though

Hi Preston, >>> As noted in the GEP FAQ, GEPs don't support variable-length arrays; >> >> that's not quite right. The problem is only with arrays of variable length >> arrays, and more generally with arrays where the element type has variable >> size (this occurs with Ada, which has all kinds of funky variable sized types, >> for example). > >

Hi Anton, and happy new year all, >>One questions though: is it possible to "verify" the results of all >>the computations somehow? Good point, and there is no automated way currently, but we can work on that. Note that simulation suffers from the 'butterfly effect', so the smallest change anywhere, (cpu, compiler etc) diverges into totally different results after a

On Fri, 26 Mar 2004, Reid Spencer wrote: > Would people other than myself find it useful to have a standardized > extension framework for LLVM? I'm thinking of something that would allow > new LLVM instructions, fundamental types, structured types, etc. This > would require significant work to allow the various pieces of LLVM > (assembler, disassembler, runtime, JIT,