similar to: [LLVMdev] Elsa and LLVM and LLVM submissions

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] Elsa and LLVM and LLVM submissions"

2007 Dec 17
0
[LLVMdev] Elsa and LLVM and LLVM submissions
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
2007 Dec 17
2
[LLVMdev] Elsa and LLVM and LLVM submissions
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
2007 Dec 17
0
[LLVMdev] Elsa and LLVM and LLVM submissions
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
2007 Dec 15
0
[LLVMdev] (no subject)
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
2007 Dec 23
1
[LLVMdev] Status of Elsa->LLVM
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
2007 Dec 22
5
[LLVMdev] Status of Elsa->LLVM
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
2007 Dec 22
0
[LLVMdev] Status of Elsa->LLVM
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
2007 Dec 21
5
[LLVMdev] Status of Elsa->LLVM
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
2007 Dec 22
0
[LLVMdev] Status of Elsa->LLVM
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
2007 Dec 21
0
[LLVMdev] [Oink-devel] Status of Elsa->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
2007 Dec 23
1
[LLVMdev] [Oink-devel] Status of Elsa->LLVM
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 >
2008 Apr 02
4
[LLVMdev] LLVMBuilder vs LLVMFoldingBuilder
Hello llvm dev peeps I would like to use an LLVMBuilder pointer as a base pointer to reference either an LLVMBuilder or an LLVMFoldingBuilder. As the methods in the Folding builder have the same names as the base class, I thought about submitting a patch whereby the base class methods would become virtual. However, the base class methods return specific types while the Folding builder, for
2008 Apr 04
0
[LLVMdev] LLVMBuilder vs LLVMFoldingBuilder
On Apr 2, 2008, at 9:54 AM, Dominic Hamon wrote: > Hello llvm dev peeps > > I would like to use an LLVMBuilder pointer as a base pointer to > reference either an LLVMBuilder or an LLVMFoldingBuilder. As the > methods > in the Folding builder have the same names as the base class, I > thought > about submitting a patch whereby the base class methods would become >
2008 May 14
3
[LLVMdev] Help needed after hiatus
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 ]
2007 Dec 08
0
[LLVMdev] [Oink-devel] Elsa and LLVM
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, Richard
2008 Apr 03
0
[LLVMdev] LLVMBuilder vs LLVMFoldingBuilder
Hi, > Another option that was discussed in #llvm is to nuke LLVMBuilder and > rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, I'd > argue for a flag in the Builder that could retain the old non-folding > functionality for debugging purposes. this plan sounds good to me. However it's not clear to me how useful a debug flag would really be. Ciao, Duncan.
2008 Apr 10
3
[LLVMdev] LLVMBuilder vs LLVMFoldingBuilder
Duncan Sands wrote: >> Another option that was discussed in #llvm is to nuke LLVMBuilder and >> rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, I'd >> argue for a flag in the Builder that could retain the old non-folding >> functionality for debugging purposes. >> > > this plan sounds good to me. However it's not clear to me how
2008 Apr 11
4
[LLVMdev] LLVMBuilder vs LLVMFoldingBuilder
Hi Dominic, +//===-- llvm/Support/IRBuilder.h - Builder for LLVM Instrs -----*- C++ -*-===// is this line the right length? It seems shorter than the similar lines below like this one: +//===----------------------------------------------------------------------===// + GetElementPtrInst *CreateStructGEP(Value *Ptr, unsigned Idx, + const char *Name =
2007 Dec 22
0
[LLVMdev] [Oink-devel] Status of Elsa->LLVM
> 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
2008 Apr 10
0
[LLVMdev] LLVMBuilder vs LLVMFoldingBuilder
Dominic Hamon wrote: > Duncan Sands wrote: >>> Another option that was discussed in #llvm is to nuke LLVMBuilder >>> and rename LLVMFoldingBuilder to LLVMBuilder. If this was the case, >>> I'd argue for a flag in the Builder that could retain the old >>> non-folding functionality for debugging purposes. >>> >> >> this plan