Re: GCC Status Report (2004-09-13)

Re: GCC Status Report (2004-09-13)

[Wolfgang Bangerth]

> PR 17324
>
>  This is a C++ case that looks like we may be stomping memory, with
>  who-knows-what unpredictable side-effects.

It wasn't exactly a pleasurable experience, but I got it down to 25 lines.
I guess that should be small enough to figure out what is going on :-)

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: GCC Status Report (2004-09-13)

[Paolo Bonzini]

 > * Top-level bootstrap [Bonzini/Nerode]

This project is complete.  Patches are in and I have submitted a 
call-for-testing which received no answer (unfortunately: the side patch 
to always enable the build-side libiberty was approved because it helps 
with binary-incompatible native compilers; but this is useless until we 
three-stage libiberty and libcpp).

So the project is finished but not enabled by default (I don't expect it 
to be in 4.0 but who knows).

Paolo

GCC Status Report (2004-09-13)

[Mark Mitchell]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]


-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com


[-- Attachment #2: gcc-status.txt --]
[-- Type: text/plain, Size: 3734 bytes --]

GCC 3.4.3
=========

I plan to do a GCC 3.4.3 release on or about November 1st, as
expected.  We seem to be reaching a pretty stable state on the GCC
3.4.x branch, and we'll continue to apply conservative fixes for
regressions there.

GCC 4.0
=======

There are 142 bugs targeted at GCC 4.0 -- which is not too bad, and
it's nice to see that RTH and others are swatting these bugs at a
pretty rapid pace.  I'm happy to see that only 32 of the bugs are
optimization bugs; those are often the hardest to fix.  Unfortunately,
some significant fraction of the 107 bugs targeted at 3.4.3 are also
GCC 4.0 bugs.

=======

Here is an update on the GCC projects for 4.0, as previously posted.

What is the status of:

* Tree-based branch prediction [Hubicka]

  September 5 

?  

I lost track of this project.

Patches to implement these projects have been submitted:

* Convert RTL passes to use pass manager [Nerode/Bonzini]

* Edges-in-vectors conversion [Elliston]

* Analysis of usage of compilation unit static variables and removal
  of spurious clobbering vdef based on the information [Zadeck]

* Vectorize unknown-loop-bound support [Golovanevsky]

* Linear loop transforms [Berlin]

* Variable expansion optimization [Eres]

* Tree-based profile-directed feedback [Hubicka]

Some have been reviewed, some have not, but we seem to be making good
progress on all of them.  I'm very pleased to see the submitters
working hard to hit these dates.

These projects have missed the target dates, and will be postponed
until GCC 4.1.  (No criticism is implied; these just didn't get done.)

September 5

* Immediate use integration [MacLeod] 

* Top-level bootstrap [Bonzini/Nerode]

* Automatic dependency for GCC builds [Weinberg]

These projects are still on the plan:

September 19

* Fix/finish --enable-mapped-location [Bothner]

* General compile-time performance improvements [Weinberg]

  (Although more may be acceptable later in Stage 3, as makes sense.)

* Use the previous project to promote non-escaping static variables
  into true ssa variables [Zadeck]

* Vectorizer peeling-for-alignment support [Golovanevsky]

* Vectorizer additional data-references support [Rosen]

* LNO branch merge [Dvorak]

=======

Some people have expressed interest in knowing which PRs I see as
particularly high priority.  For now, I'm going to confine myself to
wrong-code bugs -- of which there are 35.

For now, I've confined myself to wrong-code regressions; here are some
that concern me especially much:

PR 16381

  This is a structure layout issue, and therefore potentially
  ABI-breaking.  It's a corner case, but I'm not sure how uncommon of
  a corner case.

PR 17252

  This is an aliasing problem that looks likely to affect a fair
  amount of code. Since it looks likes Diego's testing a patch, this
  will probably go away quickly.

PR 17324

  This is a C++ case that looks like we may be stomping memory, with
  who-knows-what unpredictable side-effects.

PR 15846

  This is -fdata-sections vs. common variables; I'd really like to get
  this resolved because it does seem to be confusing people.  Jason is
  open to having a part of his patch reverted, but we need to get some
  testing cycles there.

PR 17251

  This is a problem with the ELF visibility attribute; we need to
  specify the behavior we want, and then, perhaps implement it.  Best
  we do this before 4.0 gets out and we have compatibility problems.

PR 15923

  This is a testsuite regression on PowerPC, probably involving
  varargs in some way.

There are also 40 ice-on-valid-code bugs, including several bootstrap
failures.  Those are pretty serious; in particular PR 17427, which is
a bootstrap failure on PowerPC GNU/Linux is clearly a must-fix.

Re: GCC Status Report (2004-09-13)

[Andrew Pinski]

On Sep 13, 2004, at 4:05 PM, Mark Mitchell wrote:

>
> PR 15923
>
>   This is a testsuite regression on PowerPC, probably involving
>   varargs in some way.


Actually this is only on Darwin, it does not effect linux at all.
And it happens with structs smaller than 4 bytes passed through varargs,
see related bug 14262 which does have a patch which fixes the problem
but the patch was rejected by Jim for some reason, I cannot remember
why.

Thanks,
Andrew Pinski

Re: GCC Status Report (2004-09-13)

[Jan Hubicka]

> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com
> 

> GCC 3.4.3
> =========
> 
> I plan to do a GCC 3.4.3 release on or about November 1st, as
> expected.  We seem to be reaching a pretty stable state on the GCC
> 3.4.x branch, and we'll continue to apply conservative fixes for
> regressions there.
> 
> GCC 4.0
> =======
> 
> There are 142 bugs targeted at GCC 4.0 -- which is not too bad, and
> it's nice to see that RTH and others are swatting these bugs at a
> pretty rapid pace.  I'm happy to see that only 32 of the bugs are
> optimization bugs; those are often the hardest to fix.  Unfortunately,
> some significant fraction of the 107 bugs targeted at 3.4.3 are also
> GCC 4.0 bugs.
> 
> =======
> 
> Here is an update on the GCC projects for 4.0, as previously posted.
> 
> What is the status of:
> 
> * Tree-based branch prediction [Hubicka]
> 
>   September 5 
> 
> ?  
> 
> I lost track of this project.

The patches are ready and I've just sent two for integration (one you
responded to), other three (return value predictors, dom updating fixes
and the overall switch to tree predictors) are in testing and
benchmarking now.  I understand that it is 14th intead of 5th, so if you
want to postnote the project, I won't complain strongly.
My understanding was that projects needs to be done till 29th so I
looked into some of bugfixes and compilation speed/memory issues in
meantime too (since the mainline got into somewhat unstable state) that
somewhat delayed me.

Honza

Re: GCC Status Report (2004-09-13)

[Jeffrey A Law]

On Mon, 2004-09-13 at 17:05, Mark Mitchell wrote:

September 19


* General compile-time performance improvements [Weinberg]

Q. Presumably we can still also attack memory consumption
   issues as well.    Right?

The reason I ask is I have the first in what I expect will
be a series of patches to start reducing memory consumption
and bring more sense to our data structures.

The first patch converts our freelist of SSA_NAMEs to a bitmap;
ie, we no longer chain free nodes through the TREE_CHAIN field.
This allows us to attach information like global equivalences
and range information to the SSA_NAME rather than having that
information be stored in per-pass data structures.  This is
of interest as those per-pass data structures are allocated 
multiple times per function we compile and thus result in a
fair amount of garbage.

This first patch reduces memory in a very very tiny way (probably
due to fewer dangling pointers from SSA_NAMEs to statement nodes)
and is compile time neutral.

Anyway, I wanted to get a clarification on were we stand before
pushing those changes forward.

jeff

Re: GCC Status Report (2004-09-13)

[Mark Mitchell]

Jeffrey A Law wrote:

>On Mon, 2004-09-13 at 17:05, Mark Mitchell wrote:
>
>September 19
>
>
>* General compile-time performance improvements [Weinberg]
>
>Q. Presumably we can still also attack memory consumption
>   issues as well.    Right?
>
>The reason I ask is I have the first in what I expect will
>be a series of patches to start reducing memory consumption
>and bring more sense to our data structures.
>  
>
Yes.  We have a pretty good sense that reducing memory usage correlates 
with reducing compile time, and, of course, people do not infinite RAM 
anyhow, so this is a resource we should use prudently.  The biggest 
caveat is the one you have been raising recently: that touching pages 
merely for the purpose of marking memory as free is by no means always a 
win.  But, if you can make data structures smaller in the first place, 
and just allocate less along the way, that's going to help.

So, yes, this is OK -- but please do use your judgement about the 
prudence of attempting major overhauls.  The smaller the change (whether 
in terms of lines of code or in terms of conceptual complexity) the 
better, naturally.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC Status Report (2004-09-13)

[Jeffrey A Law]

On Mon, 2004-09-13 at 23:00, Mark Mitchell wrote:
  The biggest 
> caveat is the one you have been raising recently: that touching pages 
> merely for the purpose of marking memory as free is by no means always a 
> win.  But, if you can make data structures smaller in the first place, 
> and just allocate less along the way, that's going to help.
I expect I'll be looking at allocating fewer objects in the first
place rather than trying to allocate smaller objects.

> So, yes, this is OK -- but please do use your judgement about the 
> prudence of attempting major overhauls.  The smaller the change (whether 
> in terms of lines of code or in terms of conceptual complexity) the 
> better, naturally.
OK.  Understood. 

Thanks for the clarifications,

Jeff

Re: GCC Status Report (2004-09-13)

[Jan Hubicka]

> Jeffrey A Law wrote:
> 
> >On Mon, 2004-09-13 at 17:05, Mark Mitchell wrote:
> >
> >September 19
> >
> >
> >* General compile-time performance improvements [Weinberg]
> >
> >Q. Presumably we can still also attack memory consumption
> >  issues as well.    Right?
> >
> >The reason I ask is I have the first in what I expect will
> >be a series of patches to start reducing memory consumption
> >and bring more sense to our data structures.
> > 
> >
> Yes.  We have a pretty good sense that reducing memory usage correlates 
> with reducing compile time, and, of course, people do not infinite RAM 
> anyhow, so this is a resource we should use prudently.  The biggest 
> caveat is the one you have been raising recently: that touching pages 
> merely for the purpose of marking memory as free is by no means always a 
> win.  But, if you can make data structures smaller in the first place, 
> and just allocate less along the way, that's going to help.
> 
> So, yes, this is OK -- but please do use your judgement about the 
> prudence of attempting major overhauls.  The smaller the change (whether 
> in terms of lines of code or in terms of conceptual complexity) the 
> better, naturally.

Thanks.
Just for a record - we consume roughly 4 times as much memory as 3.4 did
for common C sources.  Even tought we are down from 7 times we did week
ago, this is still major regression.

Honza

Re: GCC Status Report (2004-09-13)

[Mark Mitchell]

Jan Hubicka wrote:

>>Jeffrey A Law wrote:
>>
>>    
>>
>>>On Mon, 2004-09-13 at 17:05, Mark Mitchell wrote:
>>>
>>>September 19
>>>
>>>
>>>* General compile-time performance improvements [Weinberg]
>>>
>>>Q. Presumably we can still also attack memory consumption
>>> issues as well.    Right?
>>>
>>>The reason I ask is I have the first in what I expect will
>>>be a series of patches to start reducing memory consumption
>>>and bring more sense to our data structures.
>>>
>>>
>>>      
>>>
>>Yes.  We have a pretty good sense that reducing memory usage correlates 
>>with reducing compile time, and, of course, people do not infinite RAM 
>>anyhow, so this is a resource we should use prudently.  The biggest 
>>caveat is the one you have been raising recently: that touching pages 
>>merely for the purpose of marking memory as free is by no means always a 
>>win.  But, if you can make data structures smaller in the first place, 
>>and just allocate less along the way, that's going to help.
>>
>>So, yes, this is OK -- but please do use your judgement about the 
>>prudence of attempting major overhauls.  The smaller the change (whether 
>>in terms of lines of code or in terms of conceptual complexity) the 
>>better, naturally.
>>    
>>
>
>Thanks.
>Just for a record - we consume roughly 4 times as much memory as 3.4 did
>for common C sources.  Even tought we are down from 7 times we did week
>ago, this is still major regression.
>
I definitely agree.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC Status Report (2004-09-13)

[Mark Mitchell]

Jeffrey A Law wrote:

>On Mon, 2004-09-13 at 17:05, Mark Mitchell wrote:
>
>September 19
>
>
>* General compile-time performance improvements [Weinberg]
>
>Q. Presumably we can still also attack memory consumption
>   issues as well.    Right?
>
>The reason I ask is I have the first in what I expect will
>be a series of patches to start reducing memory consumption
>and bring more sense to our data structures.
>  
>
Yes.  We have a pretty good sense that reducing memory usage correlates 
with reducing compile time, and, of course, people do not infinite RAM 
anyhow, so this is a resource we should use prudently.  The biggest 
caveat is the one you have been raising recently: that touching pages 
merely for the purpose of marking memory as free is by no means always a 
win.  But, if you can make data structures smaller in the first place, 
and just allocate less along the way, that's going to help.

So, yes, this is OK -- but please do use your judgement about the 
prudence of attempting major overhauls.  The smaller the change (whether 
in terms of lines of code or in terms of conceptual complexity) the 
better, naturally.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: GCC Status Report (2004-09-13)

[Scott Robert Ladd]

Mark Mitchell wrote:
> Some people have expressed interest in knowing which PRs I see as
> particularly high priority.  For now, I'm going to confine myself to
> wrong-code bugs -- of which there are 35.
> 
> For now, I've confined myself to wrong-code regressions; here are some
> that concern me especially much:

Two bugs that are giving Gentoo-amd64 developers a stomache ache include 
15617 and 14631, both "wrong code" problems with SSE code generation. As 
  -mfpmath=sse is default for AMD64, this is causing problems in using 
GCC 3.4.2 for gentoo's 2004.3 release.

Neither bug is assigned, though one (14631) appears to have had an 
unsubmitted patch. I'm willing to look at these if no one else is.

..Scott

-- 
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

Re: GCC Status Report (2004-09-13)

[Mark Mitchell]

Scott Robert Ladd wrote:

> Mark Mitchell wrote:
>
>> Some people have expressed interest in knowing which PRs I see as
>> particularly high priority.  For now, I'm going to confine myself to
>> wrong-code bugs -- of which there are 35.
>>
>> For now, I've confined myself to wrong-code regressions; here are some
>> that concern me especially much:
>
>
> Two bugs that are giving Gentoo-amd64 developers a stomache ache 
> include 15617 and 14631, both "wrong code" problems with SSE code 
> generation. As  -mfpmath=sse is default for AMD64, this is causing 
> problems in using GCC 3.4.2 for gentoo's 2004.3 release.
>
> Neither bug is assigned, though one (14631) appears to have had an 
> unsubmitted patch. I'm willing to look at these if no one else is. 

I think it would be gerat if you would.  I agree that these seem like 
pretty serious issues.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com