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