search for: elsa's

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 >> for optimized and unoptimized runs: > > Cool, this is very nice! > >> Sor...

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

...rs 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 Elsa (via google) because I liked its extensible > nature. I can drop in new syntax rules easily. It was also fairly easy > to understand. We worked very hard to make it that way just so people like you can do what you are doing :-). > It was...

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 fact that it reminds one of Elsa. > > [~/elsa/ellsif] dev% ./ellsi...

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 very nice! > Sorry to add noise to the list with this....

...cessors >> 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 agree, very much. > >> I became interested in Elsa (via google) because I liked its extensible >> nature. I can drop in new syntax rules easily. It was also fairly easy >> to understand. > > We worked very hard to make it that way just so people like...

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

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

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

Wow! Cool! Hey, if you sign my contributor agreement, we can consider making your Elsa/LLVM compiler an Oink tool. Scott's intention is for Elsa to be basically "done": that is, aside from bug fixes, it shouldn't have more features. Oink is basically a bucket into which to throw tools like this one that use Elsa as a front-end. Daniel On Dec 7, 2007 6:37 AM, Ric...

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

Right, I understand that. I was hoping there was such an implementation using ANTLR since it looks like a fairly mature project. I'm not sure how stable or mature Elsa is (but comments to clarify that would be appreciated.). E.g., a quick scan of their Web page shows the comment that they only have a partial type checker. It also says their template instantiation is incomplete. --Vikram Associate Professor, Computer Science University of Illinois at Urba...

I'm linking a program (my ellsif driver) that basically brings in most of the LLVM stuff: bitcode reading, optimizations, linking, and target code generation. All of a sudden, I'm getting the following when I run: [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions -O5 <premain>: CommandLine Error: Argument 'machine-licm' defined more than once! ellsif: CommandLine Error: Argument 'machine-licm' defined more than once! It seems like the constructor for this argument is bei...

On Jul 11, 2009, at 1:41 PM, Vikram S. Adve wrote: > Right, I understand that. I was hoping there was such an > implementation using ANTLR since it looks like a fairly mature > project. Not that I'm aware of. > I'm not sure how stable or mature Elsa is (but comments to clarify > that would be appreciated.). E.g., a quick scan of their Web page > shows the comment that they only have a partial type checker. It > also says their template instantiation is incomplete. Elsa definitely has its share of problems, but it is the best...

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

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

...g the equivalent of > -parse-noop for C) this won't be able to handle a lot of interesting > cases. C++ requires a significant amount of semantic analysis just to get > parsing correct. You could surely save a lot of time reinventing the wheel by reusing an existing C++ parser, like Elsa: http://www.cs.berkeley.edu/~smcpeak/elkhound/ There are even OCaml bindings: http://www.cs.ru.nl/~tews/olmar/ These libraries were discussed on the OCaml mailing list recently: http://groups.google.com/group/fa.caml/msg/dd7dad5533647220 -- Dr Jon D Harrop, Flying Frog Consultancy Ltd....

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. To do this, I've set up a version of bunutils (based on 2.18.50) and gdb/insight (based on 6.8) to handle all the LLVM targets (except PIC...

...ddressed. The #ifdef RICH around code in CreateGEP is there because I'm not familiar with STL enough to figure out how to get an array of pointers out of a vector. :-( If someone could clue me in as to the best way to do this, I'd greatly appreciate it. I've tested this code with my Elsa->LLVM stuff and also recompiled the LLVM itself, so I'm pretty confident that the patch doesn't break anything. Since this is my first patch to LLVM and I've only been using LLVM for two weeks, please be gentle with me. If I made any glaring submission errors, I'll gladly fix...