Sorry for the long delay in this thread .. still catching up from the
break.
> > 2) Testability of optimization passes
> >
> > How much precision one can get while testing particular feature,
> > optimization pass?
>
> You can run one pass at a time, if you wanted to, using opt (or two,
> or thr
On Wed, 23 Nov 2005, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
You will need to get University of Illinois and
past/present LLVM developers to assign the copyright over to the FSF.
Yes, you've claimed it's easy, but it needs to be done. Otherwise, we are
in limbo. We
On Sun, 27 Nov 2005, Daniel Berlin wrote:
On Sun, 2005-11-27 at 11:58 -0800, Devang Patel wrote:
What makes you think implementing LTO from scratch is different here?
Here are the questions for LLVM as well as LTO folks. (To be fair,
1) Documentation
How well is the documentation so that _ne
On Sun, 2005-11-27 at 11:58 -0800, Devang Patel wrote:
> > >
> > > With our limited resources, we cannot really afford to go off on a
> > > multi-year tangent nurturing and growing a new technology just to add
> > > a
> > > new feature.
> > >
> > What makes you think implementing LTO from scratch i
> >
> > With our limited resources, we cannot really afford to go off on a
> > multi-year tangent nurturing and growing a new technology just to add
> > a
> > new feature.
> >
> What makes you think implementing LTO from scratch is different here?
I read entire thread (last msg, I read is from Mik
On Nov 23, 2005, at 10:30 AM, Diego Novillo wrote:
I'll keep an eye on the apple branch. Will gfortran work on the
branch?
I generally like to keep Java and Fortran working on it. For moments
in time, it can have various breakages, though, they tend to be
obvious/trivial to fix. For som
On Tuesday 22 November 2005 12:53, Scott Robert Ladd wrote:
> GENERIC -> GIMPLE -> LLVM -> GIMPLE -> RTL
>
> That design adds two phases (GIMPLE -> LLVM, LLVM -> GIMPLE) here --
> perhaps simple one, perhaps not. The line is very straight, but adding
> two more segments make me wonder if we'
On 11/22/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> I've been quietly watching the conversation, largely as an interested
> user as opposed to a GCC developer. One of my concerns lies with:
I have worked on some toy front ends, so I think that I am a kind of a
user also :)
> GENERI
I've been quietly watching the conversation, largely as an interested
user as opposed to a GCC developer. One of my concerns lies with:
GENERIC -> GIMPLE -> LLVM -> GIMPLE -> RTL
That design adds two phases (GIMPLE -> LLVM, LLVM -> GIMPLE) here --
perhaps simple one, perhaps not. The l
On Wednesday 23 November 2005 13:13, Chris Lattner wrote:
> I assume you're timing a release build here, not a debug build.
>
Yes, a release build.
> In any case, the LLVM time above includes the following:
> [ ... ]
>
Well, it seems that it's too early to test LLVM, then. It's both slow and
i
On Wed, 23 Nov 2005, Diego Novillo wrote:
On Tuesday 22 November 2005 13:17, Benjamin Kosnik wrote:
What about compile-time performance?
Well, it's hard to say, I have not really used LLVM extensively. The only
real data I have is compile times for SPECint:
SPECint build times (sec
On Tuesday 22 November 2005 13:17, Benjamin Kosnik wrote:
> What about compile-time performance?
>
Well, it's hard to say, I have not really used LLVM extensively. The only
real data I have is compile times for SPECint:
SPECint build times (secs)
-O2
On Tuesday 22 November 2005 11:45, Daniel Berlin wrote:
> > Another minor nit is performance. Judging by SPEC, LLVM has some
> > performance problems. It's very good for floating point (a 9%
> > advantage over GCC), but GCC has a 24% advantage over LLVM 1.2 in
> > integer code. I'm sure that is
Chris Lattner <[EMAIL PROTECTED]> writes:
| On Tue, 23 Nov 2005, Gabriel Dos Reis wrote:
| > Diego Novillo <[EMAIL PROTECTED]> writes:
| > | On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
| > | > I will work with the GCC SC and FSF on that issue once the licensing
| > | > issue is addres
On Tue, 22 Nov 2005, Diego Novillo wrote:
You will need to address two, potentially bigger, issues: license and
implementation language.
Over the last couple of years, there have been some half hearted attempts
at suggesting C++ as a new implementation language for GCC. I would
personally lov
On Tue, 23 Nov 2005, Gabriel Dos Reis wrote:
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
| > I will work with the GCC SC and FSF on that issue once the licensing
| > issue is addressed and we know LLVM is a viable option.
| >
| What purpose
Steven Bosscher wrote:
It obviously doesn't do that. ICC uses that larger register file, too,
for x86-64.
The Intel compiler can be set to compile for multiple processors,
keeping different versions of the same function in an executable and
picking which code to run based on the processor in u
> > > Diego Novillo writes:
> Over the last couple of years, there have been some half hearted attempts
> at suggesting C++ as a new implementation language for GCC. I would
> personally love to see us move to C++, but so far that has not happened.
On Tue, Nov 22, 2005 at 06:42:11PM -0
Diego Novillo wrote:
On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
I will work with the GCC SC and FSF on that issue once the licensing
issue is addressed and we know LLVM is a viable option.
What purpose would that serve? I'm not concerned about the SC, initially.
It's the deve
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
|
| > I will work with the GCC SC and FSF on that issue once the licensing
| > issue is addressed and we know LLVM is a viable option.
| >
| What purpose would that serve? I'm not concerned about
On Tuesday 22 November 2005 18:42, David Edelsohn wrote:
> I will work with the GCC SC and FSF on that issue once the licensing
> issue is addressed and we know LLVM is a viable option.
>
What purpose would that serve? I'm not concerned about the SC, initially.
It's the development community at
On Tue, Nov 22, 2005 at 06:42:11PM -0500, David Edelsohn wrote:
> > Diego Novillo writes:
>
> Diego> Over the last couple of years, there have been some half hearted
> attempts
> Diego> at suggesting C++ as a new implementation language for GCC. I would
> Diego> personally love to see us m
> Diego Novillo writes:
Diego> Over the last couple of years, there have been some half hearted
attempts
Diego> at suggesting C++ as a new implementation language for GCC. I would
Diego> personally love to see us move to C++, but so far that has not happened.
C++ is not an issue
Chris,
You will need to address two, potentially bigger, issues: license and
implementation language. You will need to get University of Illinois and
past/present LLVM developers to assign the copyright over to the FSF.
Yes, you've claimed it's easy, but it needs to be done. Otherwise, we a
> True, but GCC 4.0 produces code that is hardly better than what
> GCC 3.3 makes of it, and 4.0 is still significantly slower.
Maybe compared to your "hammer" branch. On SPARC, FSF 3.4 is definitely
better than FSF 3.3 and 4.0 not worse than 3.4.
> Just not as much as GCC 4.1 (something like 1
On Tue, 22 Nov 2005, Benjamin Kosnik wrote:
Which is why i said "It's fine to say compile time performance of the
middle end portions ew may replace should be same or better".
And if you were to look right now, it's actually significantly better in
some cases :(
http://people.redhat.com/dnovill
On Tuesday 22 November 2005 23:32, Eric Botcazou wrote:
> > > Tree-SSA managed to add new technology to the compiler without major
> > > slowdowns.
> >
> > You must be looking at different timings than I do.
> >
> > GCC 4.1 is on average almost 40% slower than GCC 3.3.
>
> That's not true for GCC 4
On Tue, 22 Nov 2005, Richard Henderson wrote:
On Tue, Nov 22, 2005 at 05:58:14PM +0100, Steven Bosscher wrote:
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM--> RTL --> asm
(trees) (trees)
This is certain
On Tue, 22 Nov 2005, Benjamin Kosnik wrote:
Another minor nit is performance. Judging by SPEC, LLVM has some
performance problems. It's very good for floating point (a 9%
advantage over GCC), but GCC has a 24% advantage over LLVM 1.2 in
integer code. I'm sure that is fixable and I only have da
On Tue, 22 Nov 2005, Steven Bosscher wrote:
On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
The initial impression I get is that LLVM involves starting from scratch.
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM
> > Tree-SSA managed to add new technology to the compiler without major
> > slowdowns.
>
> You must be looking at different timings than I do.
>
> GCC 4.1 is on average almost 40% slower than GCC 3.3.
That's not true for GCC 4.0.
--
Eric Botcazou
On Tue, 22 Nov 2005, Daniel Jacobowitz wrote:
The initial impression I get is that LLVM involves starting from scratch.
I don't quite agree that this is necessary. One of the engineering
challenges we need to tackle is the requirement of keeping a fully
functional compiler *while* we improve its
On Tuesday 22 November 2005 20:06, Richard Henderson wrote:
> > The GVM plan could take years to get to that point...
>
> Could, but probably won't. I'd have actually guessed they could
> have something functional, if not 100% robust, in 6 months given
> 2 or 3 people on the project.
Yes. But wo
On Tuesday 22 November 2005 20:21, Benjamin Kosnik wrote:
> Tree-SSA managed to add new technology to the compiler without major
> slowdowns.
You must be looking at different timings than I do.
GCC 4.1 is on average almost 40% slower than GCC 3.3.
Gr.
Steven
On Tuesday 22 November 2005 19:17, Benjamin Kosnik wrote:
> What about compile-time performance?
>
> I'd actually like to make this a requirement, regardless of the option
> chosen.
Amen.
Maybe we should pick a baseline compiler, and require that all
compile time comparisons are made wrt. that ba
On Tuesday 22 November 2005 21:18, Scott Robert Ladd wrote:
> Jan Hubicka wrote:
> > I should note that comparison to ICC is not quite fair since it lacks
> > Opteron tunning...
>
> I think you may be comparing oranges to tangerines -- not as bad as
> apples and oranges, but still potentially an in
> Jan Hubicka wrote:
> >I should note that comparison to ICC is not quite fair since it lacks
> >Opteron tunning...
>
> I think you may be comparing oranges to tangerines -- not as bad as
> apples and oranges, but still potentially an invalid comparison.
>
> In my experience the extra registers
Jan Hubicka wrote:
I should note that comparison to ICC is not quite fair since it lacks
Opteron tunning...
I think you may be comparing oranges to tangerines -- not as bad as
apples and oranges, but still potentially an invalid comparison.
In my experience the extra registers of the Opteron
On Tue, 2005-11-22 at 13:21 -0600, Benjamin Kosnik wrote:
> > Okay, but you need to understand that reasonable bounds for compiling
> > the entire program at once are usually 3x-7x more (and in the worst
> > case, even wore) than doing it seperately.
> >
> > That is the case with completely state
>
> > Which is why i said "It's fine to say compile time performance of the
> > middle end portions ew may replace should be same or better".
> >
> > And if you were to look right now, it's actually significantly better in
> > some cases :(
>
> Can you prove this assertion?
>
> Here is some dat
Benjamin Kosnik <[EMAIL PROTECTED]> writes:
| > Okay, but you need to understand that reasonable bounds for compiling
| > the entire program at once are usually 3x-7x more (and in the worst
| > case, even wore) than doing it seperately.
| >
| > That is the case with completely state of the art al
> I'd have actually guessed they could
> have something functional, if not 100% robust, in 6 months given
> 2 or 3 people on the project.
The question is the width of the gap between functional and
usable. A number of people on this thread have implied that GCC's data
structures will need
> Okay, but you need to understand that reasonable bounds for compiling
> the entire program at once are usually 3x-7x more (and in the worst
> case, even wore) than doing it seperately.
>
> That is the case with completely state of the art algorithms,
> implementation techniques, etc.
>
> It's
> Which is why i said "It's fine to say compile time performance of the
> middle end portions ew may replace should be same or better".
>
> And if you were to look right now, it's actually significantly better in
> some cases :(
Can you prove this assertion?
Here is some data:
http://people.red
On Tue, Nov 22, 2005 at 05:58:14PM +0100, Steven Bosscher wrote:
> I thought it would basically "only" replace the GIMPLE parts of the
> compiler. That is,
>
> FE--> GENERIC --> LLVM--> RTL --> asm
> (trees) (trees)
This is certainly the only way to avoid lo
On Tue, 2005-11-22 at 19:57 +0100, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Tue, 2005-11-22 at 19:25 +0100, Gabriel Dos Reis wrote:
> | > Benjamin Kosnik <[EMAIL PROTECTED]> writes:
> | >
> | > [...]
> | >
> | > | I'd actually like to make this a requirement,
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Tue, 2005-11-22 at 19:25 +0100, Gabriel Dos Reis wrote:
| > Benjamin Kosnik <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | I'd actually like to make this a requirement, regardless of the option
| > | chosen.
| >
| > Amen.
| >
|
| Uh, IPA of
On Tue, 2005-11-22 at 10:49 -0800, Richard Henderson wrote:
> On Tue, Nov 22, 2005 at 01:47:12PM -0500, Daniel Berlin wrote:
> > Uh, IPA of any sort is generally not about speed.
>
> Except that we're talking about replacing all the tree optimizations
> all of the time with llvm, which affects -O1
On Tue, Nov 22, 2005 at 01:47:12PM -0500, Daniel Berlin wrote:
> Uh, IPA of any sort is generally not about speed.
Except that we're talking about replacing all the tree optimizations
all of the time with llvm, which affects -O1. Or at least I thought
that was the suggestion...
r~
On Tue, 2005-11-22 at 19:25 +0100, Gabriel Dos Reis wrote:
> Benjamin Kosnik <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I'd actually like to make this a requirement, regardless of the option
> | chosen.
>
> Amen.
>
Uh, IPA of any sort is generally not about speed.
It's fine to say compile ti
Benjamin Kosnik <[EMAIL PROTECTED]> writes:
[...]
| I'd actually like to make this a requirement, regardless of the option
| chosen.
Amen.
-- Gaby
> First off, regardless of what direction we choose to go, I think we
> are in a great position. Finally, GCC will have all the obvious and
> standard technology that one reads in textbooks. Not long ago, GCC
> didn't even build a flowgraph, and now here we are deciding what IPA
> technology we
Daniel Berlin wrote:
2. It natively supports Alpha, Sparc, IA64, X86, and PowerPC. An
LLVM->RTL converter is not that hard, which simply removes the entire
argument anyway.
I see the phrase "doing X is not that hard" in response to many
questions about this proposal. Now, I'm arguing the diff
On Tue, 2005-11-22 at 17:58 +0100, Steven Bosscher wrote:
> On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
> > The initial impression I get is that LLVM involves starting from scratch.
>
> I thought it would basically "only" replace the GIMPLE parts of the
> compiler. That is,
>
> FE
On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
> The initial impression I get is that LLVM involves starting from scratch.
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM--> RTL --> asm
(trees)
>
> GVM, TU combination and all the associated slimming down of our IR
> data
> structures will be quite a bit of work. This is also needed for
> other
> projects
>
I believe it is more work than porting improvements to LLVM and making
LLVM usable.
Significantly more work.
>
> We would keep
> The initial impression I get is that LLVM involves starting from scratch.
> I don't quite agree that this is necessary. One of the engineering
> challenges we need to tackle is the requirement of keeping a fully
> functional compiler *while* we improve its architecture.
I don't think that it inv
On Tue, Nov 22, 2005 at 11:20:02AM -0500, Diego Novillo wrote:
> If we choose LLVM, I have more questions than ideas, take these thoughts as
> very preliminary based on incomplete information:
>
> The initial impression I get is that LLVM involves starting from scratch.
> I don't quite agree th
First off, regardless of what direction we choose to go, I think we are in
a great position. Finally, GCC will have all the obvious and standard
technology that one reads in textbooks. Not long ago, GCC didn't even
build a flowgraph, and now here we are deciding what IPA technology we
want t
59 matches
Mail list logo
