GCC Status Report (2004-09-13)

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)

[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)

[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) [--enable-mapped-location]

[Per Bothner]

Mark Mitchell wrote:

> September 19
> 
> * Fix/finish --enable-mapped-location [Bothner]

I have a patch that looks pretty good - it actually does better
on the libjava testsuite than unmodified testsuite (without
--enable-mapped-location) from a few days ago.  I.e. comparing
apples to oranges, but I have limited testing capacity.  I'll
ask for help in a following message.

As a "side effect" I essentially rewrote the Java lexer.  Not from
scratch of course, but lots of moving code around and simplifying
the code paths and data structures.  I'll also be asking people for
help on running some timing tests.

There are a few minor known unfinished pieces that are not
show-stoppers, plus I need to write ChangeLog entries.  Otherwise
(modulo testing and timing) I think its ready.  Unfortuantely, I'm
heading off for vacation/travelling for a week, but supposedly I'll
have WiFi access for most of the time (and I'll be treating it as a
working vacation).

That brings us to the Big Question: with C, C++, Fortran, Java, and
Objc (I think - needs testing) all handling --enable-mapped-location,
we may consider making it the default for 4.0.  (Converting Ada is
not done, but it doesn't look like a major job.)  That assumes I get
help fixing a few minor regressions.  The advantage of doing that is
of course is that we don't have to fight against with rot with
--enable-mapped-location.  Since I have limited volunteer time to
spend on Gcc, I really don't want to be responsible for making
sure other people's check-ins don't break --enable-mapped-location
for as long as stage3 lasts.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: GCC Status Report (2004-09-13) [--enable-mapped-location]

[Mark Mitchell]

Per Bothner wrote:

> That brings us to the Big Question: with C, C++, Fortran, Java, and
> Objc (I think - needs testing) all handling --enable-mapped-location,
> we may consider making it the default for 4.0.

If it works, and is efficient, I think that would make sense.  That was 
certainly my goal in including your project in the timeline.

>   (Converting Ada is
> not done, but it doesn't look like a major job.)  That assumes I get
> help fixing a few minor regressions.  The advantage of doing that is
> of course is that we don't have to fight against with rot with
> --enable-mapped-location.  Since I have limited volunteer time to
> spend on Gcc, I really don't want to be responsible for making
> sure other people's check-ins don't break --enable-mapped-location
> for as long as stage3 lasts.

I think there's an even bigger question: if --enable-mapped-location 
works, why have it be an option?  Why not just have it on all the time?

Do you have any performance measurements with the option enabled at this 
point?

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

Re: GCC Status Report (2004-09-13) [--enable-mapped-location]

[Per Bothner]

Mark Mitchell wrote:

> I think there's an even bigger question: if --enable-mapped-location 
> works, why have it be an option?  Why not just have it on all the time?

That is the goal, once all the front-ends have been converted and
regressions fixed.  I'd wait a little bit (at least a couple weeks)
for things to stabilize and for people to get comfortable with the
change before ripping the old code out.  (Doing so will allow
simplifying and cleaning up more than just removing the conditionals.)

> Do you have any performance measurements with the option enabled at this 
> point?

Nope.  I'm hoping for others to provide those.  And ideally help with
performance profiling and tuning.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: GCC Status Report (2004-09-13) [--enable-mapped-location]

[Mark Mitchell]

Per Bothner wrote:

>> Do you have any performance measurements with the option enabled at 
>> this point?
>
>
> Nope.  I'm hoping for others to provide those.  And ideally help with
> performance profiling and tuning.

I think you should at least try for initial numbers on whatever machine 
you're using.  Try compiling libstdc++, say, at least.  If your patches 
aren't a performance win, they're not going to be terribly compelling; 
if they are a win, as expected, then that will make them much more 
compelling.

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

Re: GCC Status Report (2004-09-13) [--enable-mapped-location]

[Matt Austern]

On Sep 16, 2004, at 11:46 AM, Mark Mitchell wrote:

> Per Bothner wrote:
>
>>> Do you have any performance measurements with the option enabled at 
>>> this point?
>>
>>
>> Nope.  I'm hoping for others to provide those.  And ideally help with
>> performance profiling and tuning.
>
> I think you should at least try for initial numbers on whatever 
> machine you're using.  Try compiling libstdc++, say, at least.  If 
> your patches aren't a performance win, they're not going to be 
> terribly compelling; if they are a win, as expected, then that will 
> make them much more compelling.

Even if this patch doesn't show an immediate performance win, isn't 
simplicity and the possibility of future improvements an argument in 
its favor?

			--Matt

Re: GCC Status Report (2004-09-13) [--enable-mapped-location]

[Per Bothner]

Mark Mitchell wrote:

> I think you should at least try for initial numbers on whatever machine 
> you're using.  Try compiling libstdc++, say, at least.  If your patches 
> aren't a performance win, they're not going to be terribly compelling; 
> if they are a win, as expected, then that will make them much more 
> compelling.

It will take a couple of days, at best, as I'll be travelling.

Any earlier C-only test didn't show a clear difference either way.

The patches are "winning" even if the immediate performance difference 
is a wash because they'll allow us to track column numbers at little
or no extra cost.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: GCC Status Report (2004-09-13) [--enable-mapped-location]

[Mark Mitchell]

Matt Austern wrote:

> On Sep 16, 2004, at 11:46 AM, Mark Mitchell wrote:
>
>> Per Bothner wrote:
>>
>>>> Do you have any performance measurements with the option enabled at 
>>>> this point?
>>>
>>>
>>>
>>> Nope.  I'm hoping for others to provide those.  And ideally help with
>>> performance profiling and tuning.
>>
>>
>> I think you should at least try for initial numbers on whatever 
>> machine you're using.  Try compiling libstdc++, say, at least.  If 
>> your patches aren't a performance win, they're not going to be 
>> terribly compelling; if they are a win, as expected, then that will 
>> make them much more compelling.
>
>
> Even if this patch doesn't show an immediate performance win, isn't 
> simplicity and the possibility of future improvements an argument in 
> its favor?

Yes, but not necessarily in Stage 3.

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

Re: GCC Status Report (2004-09-13) [--enable-mapped-location]

[Mark Mitchell]

Per Bothner wrote:

> Mark Mitchell wrote:
>
>> I think you should at least try for initial numbers on whatever 
>> machine you're using.  Try compiling libstdc++, say, at least.  If 
>> your patches aren't a performance win, they're not going to be 
>> terribly compelling; if they are a win, as expected, then that will 
>> make them much more compelling.
>
>
> It will take a couple of days, at best, as I'll be travelling.
>
> Any earlier C-only test didn't show a clear difference either way.
>
> The patches are "winning" even if the immediate performance difference 
> is a wash because they'll allow us to track column numbers at little
> or no extra cost.

Yes, I agree -- if there is no performance downside, then there is some 
upside.  I just want to check that there is indeed no downside, at least.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.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

Re: GCC Status Report (2004-09-13) [--enable-mapped-location]

[Steven Bosscher]

On Thursday 16 September 2004 20:56, Matt Austern wrote:
> Even if this patch doesn't show an immediate performance win, isn't
> simplicity and the possibility of future improvements an argument in
> its favor?

Not to mention the improved maintainability?  Having two mechanisms
side by side is one thing GCC does too often already.

If --enable-mapped-location works and does not cause regressions of
any kind, I would think making it the default and removing the old
stuff very compelling.

Gr.
Steven

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

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/