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 is different here?
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
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 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 :)
GENERIC -
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're
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 line
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
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 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
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
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
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 that
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
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 a fully
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)
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--
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
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
Benjamin Kosnik [EMAIL PROTECTED] writes:
[...]
| I'd actually like to make this a requirement, regardless of the option
| chosen.
Amen.
-- Gaby
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 time
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 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. Or
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 any sort is
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, regardless of
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 losing
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 just
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
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
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:
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
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 invalid
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
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 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 would
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
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
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 move to C++,
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 the
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
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 -0500,
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
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
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
43 matches
Mail list logo
