similar to: [LLVMdev] [Oink-devel] Elsa and LLVM

On 12/21/07, Richard Pennington <rich at pennware.com> wrote: > I'm a little further along now. I've started to put together a simple > driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think > it works). Er. Hm. Can you explain the name? The problem with names like "ellsif" is that it sounds like "else if". I like the

Daniel Wilkerson wrote: >> I've build gcc many times over the years for different target processors >> and was never able to get my head around it internally. It is incredibly >> complex. I also didn't like the fact that I had to have N copies of gcc >> to support N processors. > > Scott McPeak is rather familiar with the internals of gcc and edg and >

> I've build gcc many times over the years for different target processors > and was never able to get my head around it internally. It is incredibly > complex. I also didn't like the fact that I had to have N copies of gcc > to support N processors. Scott McPeak is rather familiar with the internals of gcc and edg and says elsa is far simpler. > I became interested in

I would really like to avoid shipping multiple preprocessors as part of the standard elsa/oink project. On 12/21/07, Taras Glek <tglek at mozilla.com> wrote: > > >> Adding test/ofmt.i as a preprocessed C file > >> Phase: Preprocessing > >> test/ofmt.i is ignored during this phase > >> > > > > What preprocessor are you using? Taras has

Chris Lattner wrote: > On Dec 22, 2007, at 2:40 AM, Richard Pennington wrote: > >> Does Elsa provide an advantage over g++? For me, understanding it is a >> big plus. ;-) In addition, Elsa has a Berkeley-like license which I >> prefer. > > Ok. If you're not planning on extending the front-end, > understandability doesn't really matter ;-). I get

I'm a little further along now. I've started to put together a simple driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think it works). The file being compiled is a "printf" function. Here are timing results for optimized and unoptimized runs: [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions Adding test/ofmt.i as a preprocessed C file

Chris Lattner wrote: > On Dec 21, 2007, at 1:08 PM, Richard Pennington wrote: > >> I'm a little further along now. I've started to put together a simple >> driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think >> it works). >> >> The file being compiled is a "printf" function. Here are timing >> results

>> Adding test/ofmt.i as a preprocessed C file >> Phase: Preprocessing >> test/ofmt.i is ignored during this phase >> > > What preprocessor are you using? Taras has already found one that is > working for him and that is licensed under BSD and that has some > features in it that he needs for source to source transformation. I > would like us to all

On Dec 22, 2007, at 2:40 AM, Richard Pennington wrote: > Does Elsa provide an advantage over g++? For me, understanding it is a > big plus. ;-) In addition, Elsa has a Berkeley-like license which I > prefer. Ok. If you're not planning on extending the front-end, understandability doesn't really matter ;-). I get where you're coming from though! > Since I only

On Dec 21, 2007, at 1:08 PM, Richard Pennington wrote: > I'm a little further along now. I've started to put together a simple > driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think > it works). > > The file being compiled is a "printf" function. Here are timing > results > for optimized and unoptimized runs: Cool, this is

I used &Idx[0]. In future, please avoid tabs in your patch. I applied your patch. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071217/056403.html - Devang On Dec 17, 2007, at 2:57 AM, Richard Pennington wrote: > Devang Patel wrote: >> On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: >>> I got the current version of LLVM via svn yesterday and

Hi, I've been writing an Elsa to LLVM interface. It has been going very well, I think both sets of software are very nice. At this point I've been able to compile and run a small program (sieve.c). I've also compiled a pretty complete version of printf(). (It seemed like a good choice because it touches many data types, varargs, etc.) I've had to make quite a few changes to Elsa

Devang Patel wrote: > On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > >> I got the current version of LLVM via svn yesterday and modified my >> code to >> use the LLVMFoldingBuilder. Very nice! >> >> My question is this: I noticed that the folding builder doesn't fold >> some >> operations, e.g. casts. Is there some reason why? If

On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > I got the current version of LLVM via svn yesterday and modified my > code to > use the LLVMFoldingBuilder. Very nice! > > My question is this: I noticed that the folding builder doesn't fold > some > operations, e.g. casts. Is there some reason why? If I implemented > some of > these unhandled cases

Hi, Apart from the Calysto project ( http://www.cs.ubc.ca/~babic/index_calysto.htm), is there any other static code analysis tool based of the LLVM framework ? Calysto may be great but it seems that the source is not available (yet?). I was quite excited by Oink/Elsa few years ago but the project is almost dead even if the C++ parser is far from being complete. It seems to me that everything is

2009/8/2 Richard Pennington <rich at pennware.com>: > Eli Friedman wrote: >> 2009/8/2 Richard Pennington <rich at pennware.com>: >>> The following fails on x86_64 because of the output constraint '0'. >>> My question is, is this legal. LLVM complains about the size difference >>> (32 vs 64), but it is the same register (ax). >>>

Hi, I've restarted my Elsa/LLVM project after three months of having real life intrude. I upgraded my LLVM source to the current trunk. I had to make a few changes to my source, e.g. LLVMFoldingBuilder became IRBuilder and several instances of "new" became "Create". Now, a test case that previously succeeded fails. I run the following script: #!/bin/sh if [ 1 -ne 0 ]

Hi, I've just moved a second Samba domain to LDAP -- it works great! However, the first domain is now dead in the water. It refuses to autenticate, and from the logs it looks like it's not find the SambaDomainName entry in the LDAP tree. Here is a diagram of how my LDAP tree is set up. dc=mycompany,dc=com |___ ou=computers |___ ou=people |___ ou=groups |___ sambaDomain=domain1 |___

On Sun, Aug 16, 2009 at 11:47 AM, Richard Pennington<rich at pennware.com> wrote: > Richard Pennington wrote: >> >> Hi, >> >> The enclosed patch preserves debug information about compilation units, >> functions, and line number information when doing bitcode linking. I'm not >> easily able to try this for non-bitcode linking. Could someone familiar

On Jul 17, 2008, at 7:51 PM, Richard Pennington wrote: > Hi, > > As part of my work with Elsa/LLVM I've been trying to wean myself from > gcc, I'm using my own preprocessor now (to eliminate gcc -E) and have > been calling ld and as directly. You should consider using the clang preprocessor :) > My question is: What assembler does the LLVM PIC target use? I'd