Re: [Patch] Qualify min(), max() and distance() in v3.

Re: [Patch] Qualify min(), max() and distance() in v3.

[Mark Mitchell]

> I feel like the development process is a little congested at the moment,
> but hopefully it will pass soon. It would be nice to have some target
> dates for the gcc-3_3-branch, however, and a bit more communication
> about what is going on, since the target release dates are hopelessly
> out of date. At the moment it's kind of hard to schedule.

I'm having a tough time.

When I set schedules, people complain that we can't do that, since we
need volunteers.  In practice, we're missing dates because people aren't
stepping up to fix regressions as quickly as we'd like.

On the other hand, without a schedule, I understand that planning is
tough.

I'll admit that I'm a bit befuddled about how to "manage"; I can say
what makes sense to put into the releases, but I don't have the
authority to manage the people.  So, I muddle along...

The best thing people can do is to fix the really high-priority 3.3
bugs, so that I fell confident about making that branch.  The most
important bugs are wrong-code, and ice-on-legal-code.

I'll make you a deal; we'll cut the branch no latter than Dec 15th.

After that, I expect the sequence you said: BIB->mainline, the new
C++ parser, and then (perhaps) some tree optimizer stuff, although
I haven't really gotten the impression that stuff is fully ready yet.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Diego Novillo]

On Wed, 04 Dec 2002, Mark Mitchell wrote:

> After that, I expect the sequence you said: BIB->mainline, the new
> C++ parser, and then (perhaps) some tree optimizer stuff, although
> I haven't really gotten the impression that stuff is fully ready yet.
> 
Whether tree SSA can be merged for 3.4 will depend on the state
of the branch by the time the Stage 1 window closes.  We are
making rapid progress but I would like to have the following in
place:

- At least two front ends working.  We already have C and it
  looks like C++ is getting there.


- General acceptance for GENERIC and GIMPLE.  GENERIC will impact
  all the front ends, as we need every front end to emit GENERIC
  so that it can then be converted into GIMPLE, which is the IL
  that all the tree optimizers operate on.
  
  Of course, a front end need only be converted to GENERIC if it
  wants to use the tree optimizers, otherwise they don't need to
  be modified at all.


- Performance issues.  Right now the code generated by the tree
  optimizers is worse than the RTL optimizers.  This is to be
  expected at this stage and the whole tree optimization process
  can be disabled.  So, in principle I don't see a real problem
  with merging the infrastructure in.
  
I see two possible scenarios regarding optimization:

(a) We merge the infrastructure with the optimizers disabled and
    keep working on them in mainline.  This has the advantage of
    exposing the code for more testing, but it might disrupt
    development.

(b) We don't merge anything for 3.4, keep working on the branch
    and merge everything for 3.5 or whenever we close the
    performance gap.


Sometimes I'm more inclined towards (b), it seems safer.


Diego.

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[David Edelsohn]

>>>>> Diego Novillo writes:

Diego> I see two possible scenarios regarding optimization:

Diego> (a) We merge the infrastructure with the optimizers disabled and
Diego> keep working on them in mainline.  This has the advantage of
Diego> exposing the code for more testing, but it might disrupt
Diego> development.

Diego> (b) We don't merge anything for 3.4, keep working on the branch
Diego> and merge everything for 3.5 or whenever we close the
Diego> performance gap.

Diego> Sometimes I'm more inclined towards (b), it seems safer.

	I would prefer (a) because that allows Tree-SSA to be a GCC
technology preview in the GCC 3.4 release to which improvements can be
merged in during later Stages of GCC 3.4 development.  We might have
enough Tree-SSA optimizations enabled by the end of Stage2/Stage3 for
Tree-SSA to be effective and useful, but it will not be abled by default
so it is safe.

David

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Gabriel Dos Reis]

David Edelsohn <dje@watson.ibm.com> writes:

| >>>>> Diego Novillo writes:
| 
| Diego> I see two possible scenarios regarding optimization:
| 
| Diego> (a) We merge the infrastructure with the optimizers disabled and
| Diego> keep working on them in mainline.  This has the advantage of
| Diego> exposing the code for more testing, but it might disrupt
| Diego> development.
| 
| Diego> (b) We don't merge anything for 3.4, keep working on the branch
| Diego> and merge everything for 3.5 or whenever we close the
| Diego> performance gap.
| 
| Diego> Sometimes I'm more inclined towards (b), it seems safer.
| 
| 	I would prefer (a) because that allows Tree-SSA to be a GCC

Since (a) depends on acceptance of GIMPLE and GENERIC, which are
invasive and quite not yet mature, I would prefer (b) given the
other invasive works already scheduled for 3.4.

-- Gaby

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[David Edelsohn]

>>>>> Gabriel Dos Reis writes:

Gaby> Since (a) depends on acceptance of GIMPLE and GENERIC, which are
Gaby> invasive and quite not yet mature, I would prefer (b) given the
Gaby> other invasive works already scheduled for 3.4.

	The lack of the Tree-SSA infrastructure in GCC 3.4 may discourage
developers from working on GCC 3.4 and encourage the further branching and
fragmentation of GCC.

David

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Mark Mitchell]

> Since (a) depends on acceptance of GIMPLE and GENERIC, which are
> invasive and quite not yet mature, I would prefer (b) given the
> other invasive works already scheduled for 3.4.

I too am presently inclined towards (b).  There are already a lot of
changes heading for 3.4; if this stuff isn't fully baked at this point,
we can wait for 3.5.

We don't need to decide now, however; we can see how things go.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Jan Hubicka]

> >>>>> Diego Novillo writes:
> 
> Diego> I see two possible scenarios regarding optimization:
> 
> Diego> (a) We merge the infrastructure with the optimizers disabled and
> Diego> keep working on them in mainline.  This has the advantage of
> Diego> exposing the code for more testing, but it might disrupt
> Diego> development.
> 
> Diego> (b) We don't merge anything for 3.4, keep working on the branch
> Diego> and merge everything for 3.5 or whenever we close the
> Diego> performance gap.
> 
> Diego> Sometimes I'm more inclined towards (b), it seems safer.
> 
> 	I would prefer (a) because that allows Tree-SSA to be a GCC
> technology preview in the GCC 3.4 release to which improvements can be
> merged in during later Stages of GCC 3.4 development.  We might have
> enough Tree-SSA optimizations enabled by the end of Stage2/Stage3 for
> Tree-SSA to be effective and useful, but it will not be abled by default
> so it is safe.

I would second to this.  I think we will get more motivation to resolve
the remaining important issues needed in order to make Tree-SSA useable
by default.

Honza
> 
> David

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Frank Ch. Eigler]

David Edelsohn <dje@watson.ibm.com> writes:

> [...]
> Diego> I see two possible scenarios regarding optimization:
> 
> Diego> (a) We merge the infrastructure with the optimizers disabled and
> Diego> keep working on them in mainline.  This has the advantage of
> Diego> exposing the code for more testing, but it might disrupt
> Diego> development.
> [...]
> 
> 	I would prefer (a) because that allows Tree-SSA to be a GCC
> technology preview in the GCC 3.4 release to which improvements can be
> merged in during later Stages of GCC 3.4 development.  [...]

Another possible technology preview aspect of tree-ssa is the mudflap
bounds-checking work.  It demonstrates a tree-rewriting transform that
adds newish functionality, flag-controlled, to the compiler, thus not
becoming a possible performance regression.  It could showcase the
value of a generic tree IR, an issue distinct from the presence of
ssa-based optimizations.


- FChE

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Jan Hubicka]

> On Wed, 04 Dec 2002, Mark Mitchell wrote:
> 
> > After that, I expect the sequence you said: BIB->mainline, the new
> > C++ parser, and then (perhaps) some tree optimizer stuff, although
> > I haven't really gotten the impression that stuff is fully ready yet.
> > 
> Whether tree SSA can be merged for 3.4 will depend on the state
> of the branch by the time the Stage 1 window closes.  We are
> making rapid progress but I would like to have the following in
> place:
> 
> - At least two front ends working.  We already have C and it
>   looks like C++ is getting there.
> 
> 
> - General acceptance for GENERIC and GIMPLE.  GENERIC will impact
>   all the front ends, as we need every front end to emit GENERIC
>   so that it can then be converted into GIMPLE, which is the IL
>   that all the tree optimizers operate on.
>   
>   Of course, a front end need only be converted to GENERIC if it
>   wants to use the tree optimizers, otherwise they don't need to
>   be modified at all.
> 
> 
> - Performance issues.  Right now the code generated by the tree
>   optimizers is worse than the RTL optimizers.  This is to be
>   expected at this stage and the whole tree optimization process
>   can be disabled.  So, in principle I don't see a real problem
>   with merging the infrastructure in.

It is understood what is needed in order to get this solved?
IE how to make RTL chain generated from GIMPLE comparable to one
generated directly from trees?

Honza

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Diego Novillo]

On Wed, 04 Dec 2002, Jan Hubicka wrote:

> It is understood what is needed in order to get this solved?
> IE how to make RTL chain generated from GIMPLE comparable to one
> generated directly from trees?
> 
In general terms, yes.  It's the traditional iterative process of
profiling some body of code to see whether we need to remove RTL
passes, add more tree passes or both.

However, we still don't have all of the fundamental tree
optimizers working, so it's not worth doing at this stage.

Another area that needs to be studied is compile time
performance.  The tree optimizers will in principle impact
compile time negatively.  However, we hope that by simplifying
initial RTL generation we can reduce compile time in the RTL
backend.


Diego.

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Joe Buck]

Diego writes:

> Whether tree SSA can be merged for 3.4 will depend on the state
> of the branch by the time the Stage 1 window closes.  We are
> making rapid progress but I would like to have the following in
> place:

[ stuff deleted ]

> - Performance issues.  Right now the code generated by the tree
>   optimizers is worse than the RTL optimizers.  This is to be
>   expected at this stage and the whole tree optimization process
>   can be disabled.  So, in principle I don't see a real problem
>   with merging the infrastructure in.

To me, this is critical.  GCC has, by some measures, slowly been getting
worse and worse.  I believe in the tree-ssa concept, but I don't think
that it should be accepted until it is a clear win.  What happens in
almost every case is that people know that a change makes things worse by 
some measures, but they like the elegance and are sure they can fix it
later.  Then it never gets fixed.  We can't force volunteers to do things,
so the only control that we have is keeping things out of the compiler
until they clearly improve it.

> I see two possible scenarios regarding optimization:
> 
> (a) We merge the infrastructure with the optimizers disabled and
>     keep working on them in mainline.  This has the advantage of
>     exposing the code for more testing, but it might disrupt
>     development.
> 
> (b) We don't merge anything for 3.4, keep working on the branch
>     and merge everything for 3.5 or whenever we close the
>     performance gap.
> 
> Sometimes I'm more inclined towards (b), it seems safer.

Likewise.

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Jan Hubicka]

> Diego writes:
> 
> > Whether tree SSA can be merged for 3.4 will depend on the state
> > of the branch by the time the Stage 1 window closes.  We are
> > making rapid progress but I would like to have the following in
> > place:
> 
> [ stuff deleted ]
> 
> > - Performance issues.  Right now the code generated by the tree
> >   optimizers is worse than the RTL optimizers.  This is to be
> >   expected at this stage and the whole tree optimization process
> >   can be disabled.  So, in principle I don't see a real problem
> >   with merging the infrastructure in.
> 
> To me, this is critical.  GCC has, by some measures, slowly been getting
> worse and worse.  I believe in the tree-ssa concept, but I don't think

What measures do you have in a mind?  From the code performance point of
view situation don't seems to be so critical according to the SPEC
testers.  Perhaps in for other architectures than i386 or other tests it
is, but that just means that we need more periodic testers to keep
quality in control.
From compile time performance point of view sitaution is different
tought :(.

Compiler is getting slower in each release but that is mostly cumulative
result of adding new features current infrastructure can't accept
cheaply...

I would like to see the reason for slowowns on SSA branch to be
understood and fixed before merging too.
On the other hand I would love to see merging to happen in 3.4 period as
too many things are getting dependent on the SSA work and we should keep
dependence chain small if possible.

Honza
> that it should be accepted until it is a clear win.  What happens in
> almost every case is that people know that a change makes things worse by 
> some measures, but they like the elegance and are sure they can fix it
> later.  Then it never gets fixed.  We can't force volunteers to do things,
> so the only control that we have is keeping things out of the compiler
> until they clearly improve it.
> 
> > I see two possible scenarios regarding optimization:
> > 
> > (a) We merge the infrastructure with the optimizers disabled and
> >     keep working on them in mainline.  This has the advantage of
> >     exposing the code for more testing, but it might disrupt
> >     development.
> > 
> > (b) We don't merge anything for 3.4, keep working on the branch
> >     and merge everything for 3.5 or whenever we close the
> >     performance gap.
> > 
> > Sometimes I'm more inclined towards (b), it seems safer.
> 
> Likewise.

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Neil Booth]

Jan Hubicka wrote:-

> Compiler is getting slower in each release but that is mostly cumulative
> result of adding new features current infrastructure can't accept
> cheaply...

I hate this slowness.  There's no reason IMO that GCC couldn't be 4
times faster than it is, without any PCH or anything.  A lot of the
code we use is just awfully inefficient.  And people are working on
more interesting things than fixing some of the real problems we have.

There's no excuse for the parser taking more time than CPP for example;
currently it takes about 4-5 times as long.  I want to see GCC so fast
that CPP is up to 5-10% of CPU time.  It's rarely much above 1 or 2%.

Neil.

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Neil Booth]

Jan Hubicka wrote:-

> Except that I don't see easy easy way to get it faster except for fixing
> some design defects (like using tree SSA :) that require quite a lot of
> effort

There must be ways of getting it faster.  lcc is a *lot* faster, a lot
smaller, and doesn't produce code that is much worse.  Its parser is well-
written; I'd bet it's faster than LCC's CPP.  Most of our parser problems
come from a poor tree IL and bison.

I vote we force GCC developers to bootstrap on 100MHz Pentia for 1 year.

Neil.

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Toon Moene]

Neil Booth wrote:

> There must be ways of getting it faster.  lcc is a *lot* faster, a lot
> smaller, and doesn't produce code that is much worse.  Its parser is well-
> written; I'd bet it's faster than LCC's CPP.  Most of our parser problems
> come from a poor tree IL and bison.
> 
> I vote we force GCC developers to bootstrap on 100MHz Pentia for 1 year.

Must be the language.

Once again I'm repeating the old adage:  People *never* complain to my 
about the speed of g77, just about the speed of the generated code.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Eric Christopher]

On Wed, 2002-12-04 at 13:39, Neil Booth wrote:
> Jan Hubicka wrote:-
> 
> > Compiler is getting slower in each release but that is mostly cumulative
> > result of adding new features current infrastructure can't accept
> > cheaply...
> 
> I hate this slowness.  There's no reason IMO that GCC couldn't be 4
> times faster than it is, without any PCH or anything.  A lot of the
> code we use is just awfully inefficient.  And people are working on
> more interesting things than fixing some of the real problems we have.
> 

Some of the advantages to working on the tree-ssa bits is that they will
(hopefully) enable us to do a better job of optimizing faster so that
the later rtl routines have less to work with and are faster as a
result.

-eric

-- 
Yeah, I used to play basketball...

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Matt Austern]

On Wednesday, December 4, 2002, at 01:03 PM, Eric Christopher wrote:

> On Wed, 2002-12-04 at 13:39, Neil Booth wrote:
>> Jan Hubicka wrote:-
>>
>>> Compiler is getting slower in each release but that is mostly 
>>> cumulative
>>> result of adding new features current infrastructure can't accept
>>> cheaply...
>>
>> I hate this slowness.  There's no reason IMO that GCC couldn't be 4
>> times faster than it is, without any PCH or anything.  A lot of the
>> code we use is just awfully inefficient.  And people are working on
>> more interesting things than fixing some of the real problems we have.
>>
>
> Some of the advantages to working on the tree-ssa bits is that they 
> will
> (hopefully) enable us to do a better job of optimizing faster so that
> the later rtl routines have less to work with and are faster as a
> result.

Except that most of the compile time is taken up in the front end.
That's what we've found at Apple for the projects we care most
about, anyway.

Are there good test cases for the 3.1 -> 3.3 compile time
regressions?  It would be interesting to study them and find out
just what has gotten slower.  If the numbers people have been
tossing around are real, then these are very serious regressions
and we should consider slipping the schedule rather than
releasing a compiler with those sorts of performance problems.

			--Matt

compile time regressions (was: merging for 3.4)

[Gerald Pfeifer]

On Wed, 4 Dec 2002, Matt Austern wrote:
> Are there good test cases for the 3.1 -> 3.3 compile time
> regressions?  It would be interesting to study them and find out
> just what has gotten slower.

PR 3083 (yes, that old) basically still applies, but has been superseded
by PR 8361 (http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=8361).

> If the numbers people have been tossing around are real then these are
> very serious regressions and we should consider slipping the schedule
> rather than releasing a compiler with those sorts of performance
> problems.

Here are some timings from that PR:
  gcc-3.0.4/bin/g++    45.45 user
  gcc-3.1.1/bin/g++    57.79 user  +27%
  gcc-3.2.1/bin/g++    59.30 user  +30%
  gcc-current/bin/g++  72.29 user  +59%

Devang asked me wrt. to number w/o optimization:

  On Fri, 25 Oct 2002, Devang Patel wrote:
> Is it possible to get numbers for compilations without optimization?

Now, that's quite interesting:

/sw/gcc-3.0.4/bin/g++
       25.60 real        24.66 user         0.63 sys
/sw/gcc-3.1.1/bin/g++
       28.44 real        26.88 user         0.98 sys
/sw/gcc-3.2.1/bin/g++
       28.71 real        27.17 user         0.65 sys
/sw/gcc-current/bin/g++
       32.14 real        31.06 user         0.59 sys

That is, we are already quite bad (and regress) without optimization.

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: compile time regressions (was: merging for 3.4)

[Jan Hubicka]

> On Wed, 4 Dec 2002, Matt Austern wrote:
> > Are there good test cases for the 3.1 -> 3.3 compile time
> > regressions?  It would be interesting to study them and find out
> > just what has gotten slower.
> 
> PR 3083 (yes, that old) basically still applies, but has been superseded
> by PR 8361 (http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=8361).
Hmm, we are definitly having some problem here :)

$ gcc -O2 generate.ii 
In file included from dltypes.h:1617,
                 from dl.h:94,
                 from generate.C:8:
program.h: In function `std::ostream& operator<<(std::ostream&, const
   TPROGRAM<T>&)':
program.h:147: warning: `TPROGRAM<T>::const_iterator' is implicitly a typename
program.h:147: warning: implicit typename is deprecated, please see the
   documentation for details
In file included from dl.h:98,
                 from generate.C:8:
depgraph.h: In member function `void COMPONENT_FACTORY::preprocessComponents()
   ':
depgraph.h:675: internal compiler error: in pop_binding, at cp/decl.c:1181
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

Honza
> 
> > If the numbers people have been tossing around are real then these are
> > very serious regressions and we should consider slipping the schedule
> > rather than releasing a compiler with those sorts of performance
> > problems.
> 
> Here are some timings from that PR:
>   gcc-3.0.4/bin/g++    45.45 user
>   gcc-3.1.1/bin/g++    57.79 user  +27%
>   gcc-3.2.1/bin/g++    59.30 user  +30%
>   gcc-current/bin/g++  72.29 user  +59%
> 
> Devang asked me wrt. to number w/o optimization:
> 
>   On Fri, 25 Oct 2002, Devang Patel wrote:
> > Is it possible to get numbers for compilations without optimization?
> 
> Now, that's quite interesting:
> 
> /sw/gcc-3.0.4/bin/g++
>        25.60 real        24.66 user         0.63 sys
> /sw/gcc-3.1.1/bin/g++
>        28.44 real        26.88 user         0.98 sys
> /sw/gcc-3.2.1/bin/g++
>        28.71 real        27.17 user         0.65 sys
> /sw/gcc-current/bin/g++
>        32.14 real        31.06 user         0.59 sys
> 
> That is, we are already quite bad (and regress) without optimization.
> 
> Gerald
> -- 
> Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: compile time regressions (was: merging for 3.4)

[Neil Booth]

Dan Nicolaescu wrote:-

> It looks like there was a significant increase in the garbage
> collection time. It's strange that GC is so expensive for C++
> compilation. 

I think GC is turning out to be a mistake, even though it saves
us from nasty memory issues.  It means we have no idea what code
is gradually getting worse; it just shows up as "GC".  And it
gives poor locality.

Neil.

Re: compile time regressions (was: merging for 3.4)

[Daniel Berlin]

On Tuesday, December 10, 2002, at 01:37  AM, Neil Booth wrote:

> Dan Nicolaescu wrote:-
>
>> It looks like there was a significant increase in the garbage
>> collection time. It's strange that GC is so expensive for C++
>> compilation.
>
> I think GC is turning out to be a mistake, even though it saves
> us from nasty memory issues.  It means we have no idea what code
> is gradually getting worse; it just shows up as "GC".  And it
> gives poor locality.
The partial solution to this is generational copying collection.
(The full solution is to use garbage collected pools/arena so that we 
are allocating things we access together, together).
Our poor locality is also generally from the fragmentation of memory 
that is occurring.
So is our large footprint.
We could at least start with a non-generational copying collector (to 
avoid needing a barrier) and see if it helps.

It's not too hard to turn gengtype into something that emits copying 
routines, reusing the mark bit as our bit to determine forwarded 
pointers.
I can actually say it's not too hard because I did it one day when i 
was bored.
Took a few hours, and i never completely finished converting (mainly 
didn't feel like transforming the ggc_test_and_set_mark calls and 
blocks at the time), but it's doable.
If you zero out the old space, you'll quickly discover where we have 
pointers to gc'd info from non-gc'd things.
:)
>
> Neil.

Re: compile time regressions (was: merging for 3.4)

[Neil Booth]

Benjamin Kosnik wrote:-

> >  >   gcc-3.0.4/bin/g++    45.45 user
> >  >   gcc-3.1.1/bin/g++    57.79 user  +27%
> >  >   gcc-3.2.1/bin/g++    59.30 user  +30%
> >  >   gcc-current/bin/g++  72.29 user  +59%
> 
> These indicate, to me, that the slowdown has nothing to do with
> libstd++-v3. There just weren't substantial changes in the library
> includes to cause this kind of slowdown between 3.0.x and 3.2.x.
> 
> It also indicates the PCH will be less and less useful unless the other
> bits are brought back to normal. Depressing.

That's what scares me about PCH - I'm afraid it'll be used as an excuse
not to fix some of the real problems we have, because "we're fast enough
now".  I'd rather wait until we have good performance without PCH before
allowing PCH, though I realize that's not gonna fly.

Neil.

Re: compile time regressions (was: merging for 3.4)

[Mike Stump]

On Tuesday, December 10, 2002, at 12:33 PM, Neil Booth wrote:
> That's what scares me about PCH - I'm afraid it'll be used as an excuse
> not to fix some of the real problems we have, because "we're fast 
> enough
> now".  I'd rather wait until we have good performance without PCH 
> before
> allowing PCH, though I realize that's not gonna fly.

No, no, you have it backwards...  PCH is going to expose all that slow 
code that should be fast, that has to be fast, so that we can fix it.  
By being 12x faster, or just 2x faster, there is _much_ less room to be 
slow, not more, really.

Re: compile time regressions (was: merging for 3.4)

[Neil Booth]

Mike Stump wrote:-

> No, no, you have it backwards...  PCH is going to expose all that slow 
> code that should be fast, that has to be fast, so that we can fix it.  
> By being 12x faster, or just 2x faster, there is _much_ less room to be 
> slow, not more, really.

But slow code in things that PCH elides won't get exposed by the very
nature of PCH.  e.g. drastic CPP slowdowns (not gonna happen!), or say
the parser.

Neil.

Re: compile time regressions (was: merging for 3.4)

[Mike Stump]

On Tuesday, December 10, 2002, at 02:23 PM, Neil Booth wrote:
>> No, no, you have it backwards...  PCH is going to expose all that slow
>> code that should be fast, that has to be fast, so that we can fix it.
>> By being 12x faster, or just 2x faster, there is _much_ less room to 
>> be
>> slow, not more, really.
>
> But slow code in things that PCH elides won't get exposed by the very
> nature of PCH.  e.g. drastic CPP slowdowns (not gonna happen!), or say
> the parser.

This is called pch build time.  It is important, just not that 
important.  In a 10 minute compile, it might be 20 seconds.  Also, by 
having cycle counter times in -freport-time, and measuring pch build 
time, one can speed that up, arbitrarily fast, if one wants.

You'll notice however, that more time is wasted reconsidering in 
cxx_finish_file however.

:-)

Re: compile time regressions (was: merging for 3.4)

[Jan Hubicka]

> Mike Stump wrote:-
> 
> > No, no, you have it backwards...  PCH is going to expose all that slow 
> > code that should be fast, that has to be fast, so that we can fix it.  
> > By being 12x faster, or just 2x faster, there is _much_ less room to be 
> > slow, not more, really.
> 
> But slow code in things that PCH elides won't get exposed by the very
> nature of PCH.  e.g. drastic CPP slowdowns (not gonna happen!), or say
> the parser.

I don't think so.  It will make parser to do about comparable amount of
work to backend, so it will bring us into more realistic picture.  Right
now for certain class of C++ code it is almost uninteresting to optimize
backend becuase parsing is so slow.  Not so for Java, fortran and many C
programs.

There is lots of time wasted in all parts of GCC (yes, CPP is now
probably the very notable exception :)

And PCH is not improtant only because of precompiled headers.  It is
first step towards whole program optimization that will bring all sorts
of new performance problem, so I am not affraid that we will once feel
that GCC is fast.

Honza
> 
> Neil.

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Daniel Berlin]

On Wed, 4 Dec 2002, Neil Booth wrote:

> Jan Hubicka wrote:-
>
> > Compiler is getting slower in each release but that is mostly cumulative
> > result of adding new features current infrastructure can't accept
> > cheaply...
>
> I hate this slowness.  There's no reason IMO that GCC couldn't be 4
> times faster than it is, without any PCH or anything.  A lot of the
> code we use is just awfully inefficient.  And people are working on
> more interesting things than fixing some of the real problems we have.

This is one of the very reasons for tree-ssa. So we can do most of the
slow crap we do in the backend (attempts at high level loop optimizations,
etc), in the frontend at a reasonable speed with good algorithms (it's
hard to do at reasonable speed in the backend because we end up trying to
recreate info we already have).
Most compiler backends consist mainly of cheap optimizations, register
allocation, and scheduling.
That's it.


> There's no excuse for the parser taking more time than CPP for example;
> currently it takes about 4-5 times as long.  I want to see GCC so fast
> that CPP is up to 5-10% of CPU time.  It's rarely much above 1 or 2%.
>
> Neil.
>

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Daniel Berlin]

On Wed, 4 Dec 2002, Joe Buck wrote:

> Diego writes:
>
> > Whether tree SSA can be merged for 3.4 will depend on the state
> > of the branch by the time the Stage 1 window closes.  We are
> > making rapid progress but I would like to have the following in
> > place:
>
> [ stuff deleted ]
>
> > - Performance issues.  Right now the code generated by the tree
> >   optimizers is worse than the RTL optimizers.  This is to be
> >   expected at this stage and the whole tree optimization process
> >   can be disabled.  So, in principle I don't see a real problem
> >   with merging the infrastructure in.
>
> To me, this is critical.  GCC has, by some measures, slowly been getting
> worse and worse.  I believe in the tree-ssa concept, but I don't think
> that it should be accepted until it is a clear win.

It's only not because it doesn't have any optimizations enabled right now
besides CCP.
Even copy propagation isn't enabled by default right now.

Once copy propagation is enabled before CCP, and DCE is run after CCP, i
would expect it will be a clear win or no lose.

This should occur before 3.4 branches, unless lightning strikes all of us
dead.

Though if it doesn't, i'd say we should wait for 3.5.


--Dan

Re: [Patch] Qualify min(), max() and distance() in v3.

[Benjamin Kosnik]

>I'm having a tough time.
>
>When I set schedules, people complain that we can't do that, since we
>need volunteers.  In practice, we're missing dates because people aren't
>stepping up to fix regressions as quickly as we'd like.
>
>On the other hand, without a schedule, I understand that planning is
>tough.
>
>I'll admit that I'm a bit befuddled about how to "manage"; I can say
>what makes sense to put into the releases, but I don't have the
>authority to manage the people.  So, I muddle along...

Unquestionably, you're doing a great job in a difficult and demanding
position. Kudos.


>The best thing people can do is to fix the really high-priority 3.3
>bugs, so that I fell confident about making that branch.  The most
>important bugs are wrong-code, and ice-on-legal-code.

Ok. Is there a list of the particular ones that should be tracked?

>I'll make you a deal; we'll cut the branch no latter than Dec 15th.
>
>After that, I expect the sequence you said: BIB->mainline, the new
>C++ parser, and then (perhaps) some tree optimizer stuff, although
>I haven't really gotten the impression that stuff is fully ready yet.

Wow! Cool. I was thinking about the tree-ssa bits, and also Vlad's
Itanium2 bundling work, but since I don't really know what's up with
that I'll let other, more capable, hands figure that out. 

I'm just glad there's a well-defined plan, man.

:)

Thanks!
-benjamin

Re: merging for 3.4 (was Re: [Patch] Qualify min(), max() ...)

[Robert Dewar]

> Once again I'm repeating the old adage:  People *never* complain to my 
> about the speed of g77, just about the speed of the generated code.

I must say this corresponds to our experience so far, we were worried about
GNAT 5 (based on GCC 3) being significantly slower to compile than GNAT 3
(based on GCC 2.8.1) but so far that has not been a significant concern
among our customers beta testing the GANT 5 technology.