Re: GCC 3.5 Status (2004-08-29)

Re: GCC 3.5 Status (2004-08-29)

[Richard Kenner]

    PS I should also note Ada still does not build at least at the last know
    report, we got from Kenner and other Ada Core people.

Right.  I was away for a week and couldn't work on it.  The problem was
first the integer cache and then some random change that made a kludge
that was used for TYPE_LANG_SPECIFIC no longer work.  The first was
fixed in that code and I removed the kludge today.

Right now with my tree I have a bootstrap, but one of the ACATS tests that
at one point worked regressed.

I'm going to try to get things more checked in before dealing with that
regression since what I have is far better tnan what's checked in now.  I
think there are still a handful of things where it isn't clear exactly how to
fix things, but I need to go through stuff more methodically to see exactly
what they are.  That should happen in the next 2-3 days.

Because any remaining bugs can be fixed in Stage 3, I don't see Ada
as a constraint on the 3.5 schedule.

Speaking of Ada, I assume we'll follow the same procedures we did in 3.4
and let Arno be the judge of what changes can go into the Ada files when,
correct?

Re: GCC 3.5 Status (2004-08-29)

[Joseph S. Myers]

On Sun, 29 Aug 2004, Daniel Berlin wrote:

> Just a note, I pasted your email into the wiki
> (www.dberlin.org/gccwiki), and edited it slightly (mainly changing []'s
> to ()'s so they don't show up as link, and making the data second level
> list elements), so that we have a nice, editable html page you can use
> to refer to.
> 
> http://www.dberlin.org/gccwiki/index.php/What%20will%20be%20in%203.5

The original call for projects - before it turned out there were 45 of 
them - suggested they'd go online as they came in.  Having people put 
their own proposals online (whether in the Wiki or in wwwdocs CVS) as part 
of submission seems like a plausible approach for future use to 
parallelise the process of putting the proposals online.

I've duly linked to the C90 status (including the original proposal) from 
the Wiki.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: GCC 3.5 Status (2004-08-29)

[Arnaud Charlet]

> I'm not sure if I'm just working around -O2 code generation
> problems in 3.4.1 or doing something more "correct"
> with respect to the bootstrap process.
> 
> Arnaud?

Certainly looks like a work around to me, to avoid a codegen problem at
-O2 in the bootstrap compiler, since you're forcing recompilation of the same
run time files at a different optimization level.

That being said, if this change can make more people able to test Ada
that would be a good reason to put this change in, although I'd rather
only do a minimal change (e.g. only do a gnatmake -f -a on the first file to
be built, and not do a -f -a on others, since they should use the newly
compiled files anyway) with proper documentation on why this peculiar
change is done.

Arno

Re: GCC 3.5 Status (2004-08-29)

[Eric Botcazou]

> > On ppc32, the problem is
> > http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html
>
> Unfortunately I don't have access to this platform. May be Eric
> as author of the patch that introduced the problem has an idea?

Err... my patch can't have retroactively introduced a problem.

-- 
Eric Botcazou

Re: GCC 3.5 Status (2004-08-29)

[Devang Patel]

On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:

> The following changes will be postponed until GCC 3.6.  These changes
> either provide too little benefit, are too risky, or will take too
> much time to complete.
>
> [snip]

> * If-conversion and vectorization of conditional code [Patel]

Two points:

1) Benefit of this work (along with Dorit's work):

	http://gcc.gnu.org/ml/gcc/2003-07/msg01355.html

2) It is implemented once entirely in apple-ppc-branch. If-conversion 
patch is being reviewed by Richard. Today I was offline so I have not 
replied his email, but I am confident that it will be OKed soon. 
Regarding second part, it requires replacing builtins with new tree 
codes. Richard and Jim explained lot of things and I'll try hard to 
complete it by deliver date.

-
Devang

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 18:24, Jakub Jelinek wrote:
> It bootstraps for me only if I use 3.3 as a bootstrap compiler,
> not when using 3.4 as a bootstrap compiler, see
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00911.html
> (this happened on ia64 and x86-64 at least).

I did not notice this one, the attached patch "cures"
the problem on my x86_64 box using 3.4.1 to bootstrap
(at the total cost of 10-15 seconds of rebuilding various things).

I'm not sure if I'm just working around -O2 code generation
problems in 3.4.1 or doing something more "correct"
with respect to the bootstrap process.

Arnaud?

I'll do more testing shortly (x86_64 starting with 3.3 and x86 with 3.3
and 3.4).

> On ppc32, the problem is
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html

Unfortunately I don't have access to this platform. May be Eric
as author of the patch that introduced the problem has an idea?

Laurent

--- Make-lang.in.orig   2004-08-30 21:13:02.824369585 +0200
+++ Make-lang.in        2004-08-30 21:22:13.595332552 +0200
@@ -988,27 +988,32 @@
 ada/treeprs.ads : ada/treeprs.adt ada/sinfo.ads ada/xtreeprs.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xtreeprs ; ./xtreeprs ../treeprs.ads )
+       (cd ada/bldtools; gnatmake -q -a -f xtreeprs ; \
+        ./xtreeprs ../treeprs.ads )

 ada/einfo.h : ada/einfo.ads ada/einfo.adb ada/xeinfo.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xeinfo ; ./xeinfo ../einfo.h )
+       (cd ada/bldtools; gnatmake -q -a -f xeinfo ; \
+        ./xeinfo ../einfo.h )

 ada/sinfo.h : ada/sinfo.ads ada/xsinfo.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xsinfo ; ./xsinfo ../sinfo.h )
+       (cd ada/bldtools; gnatmake -q -a -f xsinfo ; \
+        ./xsinfo ../sinfo.h )

 ada/nmake.adb : ada/sinfo.ads ada/nmake.adt ada/xnmake.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -b ../nmake.adb )
+       (cd ada/bldtools; gnatmake -q -a -f xnmake ; \
+        ./xnmake -b ../nmake.adb )

 ada/nmake.ads :  ada/sinfo.ads ada/nmake.adt ada/xnmake.adb ada/nmake.adb
        -$(MKDIR) ada/bldtools
        $(CP) $^ ada/bldtools
-       (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -s ../nmake.ads )
+       (cd ada/bldtools; gnatmake -q -a -f xnmake ; \
+        ./xnmake -s ../nmake.ads )

 update-sources : ada/treeprs.ads ada/einfo.h ada/sinfo.h ada/nmake.adb \
        ada/nmake.ads

Re: GCC 3.5 Status (2004-08-29)

[Florian Weimer]

* Laurent GUERBY:

> Is the requirement for not release GCC with broken Ada on x86 and x86_64
> too strong?

When was the last successful bootstrap of mainline, with Ada enabled?

I understand that Ada is already in much better shape than we expected
it to be before the tree-ssa merge (and that's certainly good news!),
but I really doubt we should make a release criterion the quality of a
component that has received very little testing by the general GCC
community.

Re: GCC 3.5 Status (2004-08-29)

[Jakub Jelinek]

On Mon, Aug 30, 2004 at 08:01:34PM +0200, Laurent GUERBY wrote:
> On Mon, 2004-08-30 at 11:06, Jakub Jelinek wrote:
> > On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> > > We had a barely working Ada compiler in 3.3 (fortunately enough for
> > > bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> > > 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
> > > on x86 and x86_64 at -O2.
> >
> > Well, fully working on x86, not working in 3.4 on 64-bit architectures
> > and not working on ppc32 (while it worked in 3.3 on all of them).
> 
> 3.3 did not have ACATS so working = bootstrap, which doesn't
> mean much for end user (I know of no one successfully using Ada with FSF
> 3.3 except for bootstraping 3.4).
> 
> 3.4 on x86_64 (so 64 bits) is not that broken, 6 fail on 2316 tests.

It bootstraps for me only if I use 3.3 as a bootstrap compiler,
not when using 3.4 as a bootstrap compiler, see
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00911.html
(this happened on ia64 and x86-64 at least).

On ppc32, the problem is
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00981.html

	Jakub

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 11:06, Jakub Jelinek wrote:
> On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> > We had a barely working Ada compiler in 3.3 (fortunately enough for
> > bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> > 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
> > on x86 and x86_64 at -O2.
>
> Well, fully working on x86, not working in 3.4 on 64-bit architectures
> and not working on ppc32 (while it worked in 3.3 on all of them).

3.3 did not have ACATS so working = bootstrap, which doesn't
mean much for end user (I know of no one successfully using Ada with FSF
3.3 except for bootstraping 3.4).

3.4 on x86_64 (so 64 bits) is not that broken, 6 fail on 2316 tests.

(Also I believe s390 and s390x results were quite good before tree-ssa)

But back to the point, is not having *all* architectures perfectly
working for a language a reason to allow breaking of previously working
architectures? 

Is the requirement for not release GCC with broken Ada on x86 and x86_64
too strong?

Laurent

Re: GCC 3.5 Status (2004-08-29)

[Mike Stump]

On Monday, August 30, 2004, at 07:26  AM, Mark Mitchell wrote:
> Right now, I'd like to focus on getting the release ready.  We can 
> have the marketing debate later, if we must.

I'd prefer that we just give our input to you, and let you pick an 
answer, and that this be done sooner, rather than at the last minute... 
  1/2 of the people won't be happy, but we have to just live with that.  
In fact, I'd say we already had the debate, and the version number 
hasn't changed, therefore, the people that wanted 4.0 lost.  
Personally, 2 new frontends and a new optimization infrastructure seems 
to me to live up to requirement...

So, feel free to just announce the decision...  whatever it is...  
Deciding to not decide, is a decision.

Re: GCC 3.5 Status (2004-08-29)

[Joe Buck]

On Sun, Aug 29, 2004 at 07:46:31PM -0700, Matt Austern wrote:
> You are not the only person who cares about C++ compilation times at 
> -O0.  This is a major concern for Apple, and I expect that improving 
> C++ -O0 compilation time will be my primary activity for some time.  I 
> don't think the current status it too awful, actually, but we do still 
> have a way to go.
> 
> Do you have any suggestions for improving -O0 compile speed?

It would seem to me that doing some relatively simple optimizations at
-O0, focused on reducing code size while preserving observable values (so
people using debuggers don't notice), should speed up -O0 by reducing the
amount of RTL that has to be turned into instructions, and reducing the
size of the files that must be processed by the assembler and linker.

Re: GCC 3.5 Status (2004-08-29)

[Jeffrey A Law]

On Mon, 2004-08-30 at 01:34, Steven Bosscher wrote:
> Also, I believe the edge-vector-branch work is also purely a speedup
> project - it will make looking up PHI arguments much faster.  As I
> have shown before on this mailing list, this is one of the major bottle
> necks for passes like DOM.
The edge-vector stuff is definitely a good thing.  However, I would
not expect a big benefit from it.

Yes, there are certain codes where it would speed up DOM in a 
meaningful way, but in general I don't expect you'll find that it's
a big improvement.  I like the edge-vector work because it means
we can rip out the hacks which we added to prevent the traversal
of the PHI arguments from becoming a huge time sink.

Speeding up DOM in the general case at this point means finding a
way to stop iteration.   Not surprisingly I've thought quite a bit
about that problem.

I haven't started any experiments, but my theory is that the cases
were iterating DOM is useful can be detected by the existence of
optimizable PHIs.

ie, if we have a degenerate PHI such as this after DOM

a1 = PHI (a0)   -- or
a1 = PHI (a0, a0) -- or
a1 = PHI (a0, a1)

Then iterating DOM may be useful.  I suspect (but certainly haven't
confirmed) that iterating if no such PHIs are found is relatively
pointless.

So we might be able to reduce iteration steps.  That would be good.
Again, I haven't played with this yet, so it's ripe for someone
to poke around.

Beyond that I've spent considerable time thinking about how to
remove the iteration step completely, but it's probably not
worth outlining those thoughts at the moment as they are
predicated on the concept that optimizable PHIs are the key to 
determining what (if anything) might be gained by iterating DOM.

Jeff

Re: GCC 3.5 Status (2004-08-29)

[Diego Novillo]

Mark has taken enough beating for the 3.5 schedule, but I think his plan
is very reasonable and I fully support it.  We are currently overloaded
with new features and we need to take a breather and start stabilizing
what we have.

$NEXTRELEASE will probably not be perfect, but $NEXTRELEASE + 1 will be
pretty good and $NEXTRELEASE + 2 will be even better.


Diego.

Re: GCC 3.5 Status (2004-08-29)

[Jan Hubicka]

> On Monday 30 August 2004 12:04, Giovanni Bajo wrote:
> > Thanks for the update. Do you think it is feasable to have a special
> > version of DCE/CCP (or a special flag in them) so that they don't destroy
> > user variables, to be used at -O0?
> 
> We discussed that, yes.  You could look into how CCP propagates
> things like addresses and so on, and figure out other things that
> cause us to lose the user's variable.
> DCE is not a real problem.  If CCP would just not turn so many
> statements into dead code, it would work ;-)

I think all we need is to avoid CCP on user variables so user can change
their value and DCE killing whole statements so user can breakpoint.
Perhaps we can even consider idea of passing down the NOPs for
statements that have completely no effect.  This should be embeddable
into existing CCP/DCE code... perhaps ;)

Honza
> 
> Gr.
> Steven
> 

Re: GCC 3.5 Status (2004-08-29)

[Jan Hubicka]

> On Monday 30 August 2004 02:53, Mark Mitchell wrote:
> > >Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
> > >just about every project using GCC complaining about how GCC gets slower
> > >with each release?
> >
> > Obviously, this is not ideal.  However, we have few practical
> > alternatives.  I am not convinced that any further delay will get us
> > better results.  I do not see a broad committment to improving
> > compile-time speed when optimizing: in fact, I got zero proposals from
> > people planning to work specifically on that issue.
> 
> It is funny that you say here that you got zero proposals, yet you
> had a section in your mail:
> > -------------------------
> > Compile-Time Improvements
> > -------------------------
> > 
> > There were three submissions relating primarily to compile-time
> 
> Also, I believe the edge-vector-branch work is also purely a speedup
> project - it will make looking up PHI arguments much faster.  As I
> have shown before on this mailing list, this is one of the major bottle
> necks for passes like DOM.
> 
> Merging the LNO ivopts is another pass that could help win back speed
> because it would allow us to kill the old loop optimizer (ie. loop.c 
> and unroll.c) and all the yuckie-ness that it causes, like
> reconstructing the CFG, recomputing dominance, recomputing loop info,
> etc. etc.  All of that is expensive, and removing expensive things is
> a good thing...
> 
> Anyway, you are probably right that there appear to be few people
> working *specifically* on speeding up the compiler.  But many people
> work on replacing expensive RTL optimizations with cheaper tree ones.

Also there are are certainly people (at least me ;) who seriously hope
to do some work before the code is frozen, but merging existing work is
a priority.  So I wrote only the tasks for whose I have something ready
with hope that I will also manage to figure out how to kill some of
perofmrance/memory problems on the way too.  I think number of these can
go to stage3 anyway.

Honza

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Dorit Naishlos wrote:

>>If you disagree with my decisions, feel free to send me a message
>>explaining why you think that the decision was inappropriate.  I will
>>consider your position, but you will have to be convincing in order to
>>change my mind.  To be convincing, make sure you quantify the win: it
>>you want me to believe that your optimization is worthwhile tell me
>>how much it improves a well-known benchmark.
>>    
>>
>
>  
>
>>The following changes will be postponed until GCC 3.6.  These changes
>>either provide too little benefit, are too risky, or will take too
>>much time to complete.
>>
>>...
>>* Vectorizer misaligned-loads support [Naishlos]
>>    
>>
>
>Let me try to convince you to change this decision:
>
>1. Alignment is the number one limiting factor for vectorization on
>mainline right now. Without this we can't vectorize anything that uses
>pointers, for example. Together with the patches for unknown loop bound and
>peeling for aligning a store (proposals that were accepted for 3.5), we
>will be able to vectorize loops of the following (very basic and very
>common) form:
>   "while (--n) *q++ = *a++ + *b++".
>
>2. Risk-free. It is entirely encapsulated within -ftree-vectorize which is
>disabled by default (so no risks if not explicitly enabled).
>  
>
I disagree.  The risk is that it will break -ftree-vectorize, making 
this valuable new feature less useful.

Let's do the other things first.  If you get it all wrapped up in a nice 
neat package with a nice neat bow, we can reconsider.  :-)

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

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Steven Bosscher wrote:

>On Monday 30 August 2004 02:53, Mark Mitchell wrote:
>  
>
>>>Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
>>>just about every project using GCC complaining about how GCC gets slower
>>>with each release?
>>>      
>>>
>>Obviously, this is not ideal.  However, we have few practical
>>alternatives.  I am not convinced that any further delay will get us
>>better results.  I do not see a broad committment to improving
>>compile-time speed when optimizing: in fact, I got zero proposals from
>>people planning to work specifically on that issue.
>>    
>>
>
>It is funny that you say here that you got zero proposals, yet you
>had a section in your mail:
>  
>
I had zero proposals that described among their benefits compile-time 
speed *when optimizing*.  Perhaps Elliston's work will indeed help with 
that, but it wasn't called out seprately.  I'm all for that work on lots 
of levels, which is why when we were talking about projects we could 
trade for aliasing, I suggested hanging on to that one.

>Merging the LNO ivopts is another pass that could help win back speed
>because it would allow us to kill the old loop optimizer (ie. loop.c 
>and unroll.c) and all the yuckie-ness that it causes, like
>reconstructing the CFG, recomputing dominance, recomputing loop info,
>etc. etc.  All of that is expensive, and removing expensive things is
>a good thing...
>
>Anyway, you are probably right that there appear to be few people
>working *specifically* on speeding up the compiler.  But many people
>work on replacing expensive RTL optimizations with cheaper tree ones.
>  
>
Note that "merge LNO" is still on the plan, and I will be helping with 
that where I can.  Is the ivopts stuff already there,  or is it 
different?  If it is already there, then perhaps you should work on 
getting the old loop optimizer ready to die, so that we can do as you 
suggest above.  That might be a bigger, and easier to achieve, 
compile-time-when-optimizing improvement than Dan's stuff.

>>Maintaining compilation speed was a precondition set by the SC for the
>>tree-ssa merge.  If that condition was not met, then perhaps the merge
>>should not have been performed.  The fact that it was probably indicates
>>that people weren't too worried about these compile-time effects.
>>    
>>
>
>We discussed compile time back then and it was believed that we could
>win back enough speed before stage3 to get back to around GCC 3.4 speeds,
>which is IMO a good start.  After that, the Summit happened and suddenly
>everyone was working on re-doing much of tree-ssa.  We're also slower
>now than we were at the merge point.
>So yes, in retrospect perhaps the merge did come too early.
>  
>
It's water under the bridge in any case.  But, now, we have to decide 
what to do next.

>>I continue to think it will take at least another several months to
>>really get to the point where tree-ssa is unambiguously better
>>(consistently better code, consistently better compile-times, fewer
>>bugs) than GCC 3.4.  If people want to put GCC 3.5 off until next June,
>>and SC approves, it's OK with me.
>>    
>>
>
>If we can restrict ourselves to the features proposed in your list,
>and work on just getting those items ready, releasing GCC 3.5 later
>would IMHO be much better than rushing it out in January.
>  
>
I think it will be very hard to keep people from doing more stuff.  The 
argument is going to be "my thing is ready, and tested, and seems to 
help something, so why can't it go in?"  But each of those changes will 
introduce follow-on issues.

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

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Daniel Berlin wrote:

>
>
> On Mon, 30 Aug 2004, Mark Mitchell wrote:
>
>> Steven Bosscher wrote:
>>
>>> On Monday 30 August 2004 03:12, Mark Mitchell wrote:
>>>
>>>> Perhaps you can wait until SRA runs, and then just DTRT for objects 
>>>> that
>>>> get SRA'd.
>>>>
>>>
>>> Alias structured are never SRA'd.
>>>
>> Certainly, in Dan's example:
>>
>> x = a.f
>> c = a.e
>> a.e = 5
>> c = a.f
>>
>> it should be possible to SRA "a" without any alias information at all,
>
>
> Yes, you could, if you effectively ignored what the SSA infrastructure 
> tells you (that they do overlap), and try to figure it out on your own.
>
> This seems like a bad idea, IMHO.

In the abstract, yes.

However, sometimes it's appropriate to do something expedient to get 
from point A to point B.  As an example, the load-hoisting/store-sinking 
patch for the RTL optimizers was hardly a thing of beauty -- but did 
make a fair amount of code go quicker and wasn't responsible for very 
many bugs.  I'm glad it was in GCC -- and I'm glad that now we have real 
optimizers and can throw that stuff out!

I'm not arguing that we ought to do what I suggested; only that it's a 
possible alternative.  And that we should consider localized solutions 
(in this case, hacks to SRA, say) rather than just global solutions 
(change all representations for V_USE, adjust passes to understand 
that).  Sometimes one approach is better, sometimes the other, but both 
should be in play, especially if there is a big time/risk tradeoff.  (I 
have no idea how hard it would be to make SRA smarter; maybe there is no 
time win, in which case that suggestion is much weaker.)

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

Re: GCC 3.5 Status (2004-08-29)

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> >>-- 
> >>Mark Mitchell
> >>CodeSourcery, LLC
> >>(916) 791-8304
> >>mark@codesourcery.com
> >>
> >>   
> >>
> >
> > 
> >
> >>* Tree-based coverage [Hubicka]
> >>   
> >>
> >
> >Perhaps I should note that current RTL based coverage is now broken in
> >several interesting ways.  
> >
> I did understand that from your original project proposal, but thank you 
> for the reminder.  I understand that problem, but I don't see it as a 
> must-have for a release.

me neither, so lets see how things will shape up in next few weeks.
There are definitly more important things to do.

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

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Jan Hubicka wrote:

>>-- 
>>Mark Mitchell
>>CodeSourcery, LLC
>>(916) 791-8304
>>mark@codesourcery.com
>>
>>    
>>
>
>  
>
>>* Tree-based coverage [Hubicka]
>>    
>>
>
>Perhaps I should note that current RTL based coverage is now broken in
>several interesting ways.  
>
I did understand that from your original project proposal, but thank you 
for the reminder.  I understand that problem, but I don't see it as a 
must-have for a release.

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

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Richard Kenner wrote:

>    I think that GCC 3.5 is going to be a good release.  I also think that 
>    the first release with major new technology (tree-ssa is easily the 
>    biggest change to GCC in a decade) is going to have dot-zero properties: 
>    it won't work perfectly for all people all of the time.
>
>OK, I'm now totally confused.
>
>If the "biggest change to GCC in a decade" doesn't justify changing the major
>version number in your mind, then what would?
>  
>
I have an answer to that question, but I don't think it's an important 
question right now, and I've said all along that I didn't feel 
passionately about it.

Right now, I'd like to focus on getting the release ready.  We can have 
the marketing debate later, if we must.

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

Re: GCC 3.5 Status (2004-08-29)

[Jan Hubicka]

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

> 
> * Tree-based coverage [Hubicka]

Perhaps I should note that current RTL based coverage is now broken in
several interesting ways.  I will see what can I do on both fronts
(putting things together to get tree coverage finished, perhaps disabled
by default, and try to fix the SSA optimizers to not mess up the CFG
structure too badly for RTL coverge) after finishing the other two
projects.

Honza
> 
> * Aliasing improvements for structure fields [Berlin]
> 
> * Value range propagation [Novillo]
> 
> * CFG-based inliner [Hastings]
> 
> * Vectorizer misaligned-loads support [Naishlos]
> 
> * Vectorizer pattern recognition support [Naishlos]
> 
> * If-conversion and vectorization of conditional code [Patel]
> 
> * SMS improvements [Hagog, Markovitch]

Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

On Mon, 30 Aug 2004, Mark Mitchell wrote:

> Steven Bosscher wrote:
>
>> On Monday 30 August 2004 03:12, Mark Mitchell wrote:
>> 
>>> Perhaps you can wait until SRA runs, and then just DTRT for objects that
>>> get SRA'd.
>>> 
>> 
>> Alias structured are never SRA'd.
>> 
> Certainly, in Dan's example:
>
> x = a.f
> c = a.e
> a.e = 5
> c = a.f
>
> it should be possible to SRA "a" without any alias information at all,

Yes, you could, if you effectively ignored what the SSA infrastructure 
tells you (that they do overlap), and try to figure it out on your 
own.

This seems like a bad idea, IMHO.

--Dan

Re: GCC 3.5 Status (2004-08-29)

[Jakub Jelinek]

On Mon, Aug 30, 2004 at 01:02:34PM +0200, Laurent GUERBY wrote:
> On Mon, 2004-08-30 at 12:22, Richard Kenner wrote:
> > >    Is Ada functioning a requirement for the release?  If so it seems a
> > >    moderately bad idea to go into stage 3 with it totally busted.
> > 
> > The answer to the first question has always been "no".  But in practice,
> > my expectation is that it will work fine on the release.
> 
> We had a barely working Ada compiler in 3.3 (fortunately enough for
> bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
> 3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass

Well, fully working on x86, not working in 3.4 on 64-bit architectures
and not working on ppc32 (while it worked in 3.3 on all of them).

	Jakub

Re: GCC 3.5 Status (2004-08-29)

[Laurent GUERBY]

On Mon, 2004-08-30 at 12:22, Richard Kenner wrote:
> >    Is Ada functioning a requirement for the release?  If so it seems a
> >    moderately bad idea to go into stage 3 with it totally busted.
> 
> The answer to the first question has always been "no".  But in practice,
> my expectation is that it will work fine on the release.

We had a barely working Ada compiler in 3.3 (fortunately enough for
bootstraping 3.4 and 3.5 on x86 and x86_64), a fully working compiler on
3.4 (100% pass on x86 at -O0) and it looks like 3.5 will have 100% pass
on x86 and x86_64 at -O2.

I believe it's reasonable now to make it a requirement that Ada works in
future GCC releases, at least on x86 and x86_64 with no regression.

Laurent

Re: GCC 3.5 Status (2004-08-29)

[Paolo Bonzini]

 > There was agreement that these would be
> tackled after the merge, possibly by running a couple of cleanup optimization
> passes (DCE/CCP).

CFG-transparent expansion did introduce a cleanup pass at -O0, because 
the cleanup that is done while the CFG is built, is now done at -O0 as 
well.  This is responsible of the -O0 3-4% speed increase brought in by 
CFG-transparent expansion.

Paolo

Re: GCC 3.5 Status (2004-08-29)

[Dorit Naishlos]

> If you disagree with my decisions, feel free to send me a message
> explaining why you think that the decision was inappropriate.  I will
> consider your position, but you will have to be convincing in order to
> change my mind.  To be convincing, make sure you quantify the win: it
> you want me to believe that your optimization is worthwhile tell me
> how much it improves a well-known benchmark.

> The following changes will be postponed until GCC 3.6.  These changes
> either provide too little benefit, are too risky, or will take too
> much time to complete.
>
> ...
> * Vectorizer misaligned-loads support [Naishlos]

Let me try to convince you to change this decision:

1. Alignment is the number one limiting factor for vectorization on
mainline right now. Without this we can't vectorize anything that uses
pointers, for example. Together with the patches for unknown loop bound and
peeling for aligning a store (proposals that were accepted for 3.5), we
will be able to vectorize loops of the following (very basic and very
common) form:
   "while (--n) *q++ = *a++ + *b++".

2. Risk-free. It is entirely encapsulated within -ftree-vectorize which is
disabled by default (so no risks if not explicitly enabled).

3. Chances of meeting deadline - yes, Sept. 19 is aggressive. But note that
we already had this functionality implemented completely on the
apple-ppc-branch a couple of months ago, but using target builtins instead
of new tree-codes. Introducing the new tree-codes indeed takes some time,
but it may be doable by September 19th, considering the fast progress made
together with Richard. Given the huge benefit and zero risk, I think it's
worth while to give it a chance. What do you say?

thanks,
dorit

Re: GCC 3.5 Status (2004-08-29)

[Richard Kenner]

    I notice that the, uh, "project" to get Ada bootstrapping (Kenner,
    when can we expect this?) is not listed.  These changes will
    presumably be accepted in stage 3?

Because it's not a "project" in the sense of new development, but rather
bugs that Ada triggers in middle-end code.   Fixing bugs is Stage 3 work.
So the timing of the Ada work is not relevent to entering Stage 3.

    However, I'm beginning to worry that Ada is going to delay the release
    of GCC 3.5 substantially if it's not bootstrapping soon, because the
    long period without Ada bootstrapping is likely to lead to bug
    discoveries when Ada is revived from the dead.

Well it was bootstrapping on and off but indeed various changes have broken
it for about two weeks.  Part of the reason for the long period was that I
was in Europe for a meeting for about a week.

In any event, as of yesterday afternoon, I have it bootstrapping in my tree.
It should be bootstrapping again in the GCC CVS in a day or so.  It'll be
more work to get it ACATS clean because some of the kludges I used to work
around bugs will need to be converted into the proper fix.

    Is Ada functioning a requirement for the release?  If so it seems a
    moderately bad idea to go into stage 3 with it totally busted.

The answer to the first question has always been "no".  But in practice,
my expectation is that it will work fine on the release.

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 12:04, Giovanni Bajo wrote:
> Thanks for the update. Do you think it is feasable to have a special
> version of DCE/CCP (or a special flag in them) so that they don't destroy
> user variables, to be used at -O0?

We discussed that, yes.  You could look into how CCP propagates
things like addresses and so on, and figure out other things that
cause us to lose the user's variable.
DCE is not a real problem.  If CCP would just not turn so many
statements into dead code, it would work ;-)

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Richard Kenner]

    I think that GCC 3.5 is going to be a good release.  I also think that 
    the first release with major new technology (tree-ssa is easily the 
    biggest change to GCC in a decade) is going to have dot-zero properties: 
    it won't work perfectly for all people all of the time.

OK, I'm now totally confused.

If the "biggest change to GCC in a decade" doesn't justify changing the major
version number in your mind, then what would?

Re: GCC 3.5 Status (2004-08-29)

[Giovanni Bajo]

Steven Bosscher wrote:

>> As for C++ programs, I would like to remember that when tree-ssa was
>> merged, there were big C++ compile time issues at -O0, which used to
>> be in the merge requirement list, but were not met. There was
>> agreement that these would be tackled after the merge, possibly by
>> running a couple of cleanup optimization passes (DCE/CCP). I never
>> heard of this project again since then, and the issues seems to have
>> been forgotten.
>
> The issue is not forgotten.  We've tried it and even just the
> combination of DCE/CCP destroys too much of the original program
> (e.g. user variables) for it to be debugable.

Thanks for the update. Do you think it is feasable to have a special version of
DCE/CCP (or a special flag in them) so that they don't destroy user variables,
to be used at -O0?

Giovanni Bajo

Re: GCC 3.5 Status (2004-08-29)

[Joseph S. Myers]

On Sun, 29 Aug 2004, Andrew Pinski wrote:

> I should note that the bootstrap time feels longer but I could be imagining
> things.

Bootstrap plus testsuite run time has been slowing down, by actual 
observation (3.5 hours three months ago, 4 hours now; 45 minutes 3.5 years 
ago), but because of the additional code being added to the compilers, 
runtime libraries and testsuites that isn't really something to use as a 
release criterion; users only build a release once (or once per system).  
(I'd be very unlikely to object to a testsuite addition on the grounds of 
increased testing time.)  The time to build a fixed body of code with 
different compilers, as shown for example in the SPEC timings, is the more 
useful comparison since it avoids mixing the two variables of what is 
being compiled and what is doing the compiling.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 3.5
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 02:53, Mark Mitchell wrote:
> >Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
> >just about every project using GCC complaining about how GCC gets slower
> >with each release?
>
> Obviously, this is not ideal.  However, we have few practical
> alternatives.  I am not convinced that any further delay will get us
> better results.  I do not see a broad committment to improving
> compile-time speed when optimizing: in fact, I got zero proposals from
> people planning to work specifically on that issue.

It is funny that you say here that you got zero proposals, yet you
had a section in your mail:
> -------------------------
> Compile-Time Improvements
> -------------------------
> 
> There were three submissions relating primarily to compile-time

Also, I believe the edge-vector-branch work is also purely a speedup
project - it will make looking up PHI arguments much faster.  As I
have shown before on this mailing list, this is one of the major bottle
necks for passes like DOM.

Merging the LNO ivopts is another pass that could help win back speed
because it would allow us to kill the old loop optimizer (ie. loop.c 
and unroll.c) and all the yuckie-ness that it causes, like
reconstructing the CFG, recomputing dominance, recomputing loop info,
etc. etc.  All of that is expensive, and removing expensive things is
a good thing...

Anyway, you are probably right that there appear to be few people
working *specifically* on speeding up the compiler.  But many people
work on replacing expensive RTL optimizations with cheaper tree ones.


> Maintaining compilation speed was a precondition set by the SC for the
> tree-ssa merge.  If that condition was not met, then perhaps the merge
> should not have been performed.  The fact that it was probably indicates
> that people weren't too worried about these compile-time effects.

We discussed compile time back then and it was believed that we could
win back enough speed before stage3 to get back to around GCC 3.4 speeds,
which is IMO a good start.  After that, the Summit happened and suddenly
everyone was working on re-doing much of tree-ssa.  We're also slower
now than we were at the merge point.
So yes, in retrospect perhaps the merge did come too early.


> I continue to think it will take at least another several months to
> really get to the point where tree-ssa is unambiguously better
> (consistently better code, consistently better compile-times, fewer
> bugs) than GCC 3.4.  If people want to put GCC 3.5 off until next June,
> and SC approves, it's OK with me.

If we can restrict ourselves to the features proposed in your list,
and work on just getting those items ready, releasing GCC 3.5 later
would IMHO be much better than rushing it out in January.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 04:00, Giovanni Bajo wrote:
> Mark Mitchell wrote:
> > Otherwise, I think we
> > proceed, and accept that the release will be useful to some people
> > and less useful to others.  (It will, for example, be useful to
> > people who need support for new targets, or want gfortran, or want
> > faster non-optimizing compile times, which we are now seeing for some
> > C++ programs.)
>
> As for C++ programs, I would like to remember that when tree-ssa was
> merged, there were big C++ compile time issues at -O0, which used to be in
> the merge requirement list, but were not met. There was agreement that
> these would be tackled after the merge, possibly by running a couple of
> cleanup optimization passes (DCE/CCP). I never heard of this project again
> since then, and the issues seems to have been forgotten.

The issue is not forgotten.  We've tried it and even just the
combination of DCE/CCP destroys too much of the original program
(e.g. user variables) for it to be debugable.


> I am sure I am not the only one who cares
> the only one who cares about C++ compilation times at -O0: we got
> substantially better with 3.4 (even wrt 2.95), but now we are regressing
> way too much.

I believe a lot of people care.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Steven Bosscher wrote:

>On Monday 30 August 2004 03:12, Mark Mitchell wrote:
>  
>
>>Perhaps you can wait until SRA runs, and then just DTRT for objects that
>>get SRA'd.
>>    
>>
>
>Alias structured are never SRA'd.
>  
>
Certainly, in Dan's example:

x = a.f
c = a.e
a.e = 5
c = a.f

it should be possible to SRA "a" without any alias information at all, 
other than knowing that in C fields cannot overlap and that "a" is a 
struct, rather than a union.  I'm not saying that our implementation can 
do this; only that, it should be possible.

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

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 03:12, Mark Mitchell wrote:
> Perhaps you can wait until SRA runs, and then just DTRT for objects that
> get SRA'd.

Alias structured are never SRA'd.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Gabriel Dos Reis wrote:

>Mark Mitchell <mark@codesourcery.com> writes:
>
>| Gabriel Dos Reis wrote:
>| 
>| >Mark Mitchell <mark@codesourcery.com> writes:
>| >
>| >| Gabriel Dos Reis wrote:
>| > | | >Making regular bug-fix releases at regularly spaced times makes
>| > good
>| >| >sense to me.  What I'm unclear about is what we want for the *major*
>| >| >releases.  Do we just want them every 6 months?  Do we drive it by
>| >| >quality?  If by quality, what are the quality criteria?  I suspect
>| >| >
>| >| We cannot drive it purely by quality, since we will never get quality
>| >| unless we decide that we're going to make a release.  The level of
>| >| bug-fixing activity goes up steeply as we approach a release: people
>| >| start to fear that "their" platform/language/etc. will not work well.
>| >| That's why we use a combination: drive by time, and then push for
>| >| quality towards that date.
>| > | | >| they can lead to lower quality, as more and more changes go
>| > in,
>| >| >| sometimes without corresponding problem-solving efforts.  I also don't
>| >| >| think that "wait until it is ready" is a practical method for a
>| >| >| project this big with this much change and with so much
>| >| >| inter-dependency between components.
>| >| >
>| >| >Again, I agree.  However, because the project is that big, I believe
>| >| >branching  proposals should meet consensus among developers.
>| >| >
>| >| In contrast, I don't see consensus as achievable in this group.  We
>| >
>| >That says a lot.
>| >
>| Note that I didn't say "cooperation"; I said "consensus", which means
>| that everyone agrees.
>
>No.  "everyone agrees" means "unanimity", and I consciously avoided
>that term.
>  
>
Well, since I didn't know what the word meant, then you shouldn't read 
too much into what I said. :-)

But I do think that our key stakeholders have very divergent 
objectives.  At the GCC summit, one person I respect told me we should 
do releases every two weeks; another I respect equally much recommended 
once a year.  I try to balance all the opinions to come up with a 
reasonable plan; to me, that's the "M" in "RM".  Unless the SC tells me 
otherwise, of course.

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

Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| 
| >Mark Mitchell <mark@codesourcery.com> writes:
| >
| >| Gabriel Dos Reis wrote:
| > | | >Making regular bug-fix releases at regularly spaced times makes
| > good
| >| >sense to me.  What I'm unclear about is what we want for the *major*
| >| >releases.  Do we just want them every 6 months?  Do we drive it by
| >| >quality?  If by quality, what are the quality criteria?  I suspect
| >| >
| >| We cannot drive it purely by quality, since we will never get quality
| >| unless we decide that we're going to make a release.  The level of
| >| bug-fixing activity goes up steeply as we approach a release: people
| >| start to fear that "their" platform/language/etc. will not work well.
| >| That's why we use a combination: drive by time, and then push for
| >| quality towards that date.
| > | | >| they can lead to lower quality, as more and more changes go
| > in,
| >| >| sometimes without corresponding problem-solving efforts.  I also don't
| >| >| think that "wait until it is ready" is a practical method for a
| >| >| project this big with this much change and with so much
| >| >| inter-dependency between components.
| >| >
| >| >Again, I agree.  However, because the project is that big, I believe
| >| >branching  proposals should meet consensus among developers.
| >| >
| >| In contrast, I don't see consensus as achievable in this group.  We
| >
| >That says a lot.
| >
| Note that I didn't say "cooperation"; I said "consensus", which means
| that everyone agrees.

No.  "everyone agrees" means "unanimity", and I consciously avoided
that term.

-- Gaby

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Gabriel Dos Reis wrote:

>Mark Mitchell <mark@codesourcery.com> writes:
>
>| Gabriel Dos Reis wrote:
>| 
>| >Making regular bug-fix releases at regularly spaced times makes good
>| >sense to me.  What I'm unclear about is what we want for the *major*
>| >releases.  Do we just want them every 6 months?  Do we drive it by
>| >quality?  If by quality, what are the quality criteria?  I suspect
>| >
>| We cannot drive it purely by quality, since we will never get quality
>| unless we decide that we're going to make a release.  The level of
>| bug-fixing activity goes up steeply as we approach a release: people
>| start to fear that "their" platform/language/etc. will not work well.
>| That's why we use a combination: drive by time, and then push for
>| quality towards that date.
>| 
>| >| they can lead to lower quality, as more and more changes go in,
>| >| sometimes without corresponding problem-solving efforts.  I also don't
>| >| think that "wait until it is ready" is a practical method for a
>| >| project this big with this much change and with so much
>| >| inter-dependency between components.
>| >
>| >Again, I agree.  However, because the project is that big, I believe
>| >branching  proposals should meet consensus among developers.
>| >
>| In contrast, I don't see consensus as achievable in this group.  We
>
>That says a lot.
>  
>
Note that I didn't say "cooperation"; I said "consensus", which means 
that everyone agrees.

This is a group that cooperates well, but I don't think it's very easy 
to reach consenus among groups with O(100) people.  We often don't even 
get consensus on technical issues; we often instead defer to a 
maintainer to make a decision, or put off making one altogether.  When 
we do try for consensus, it's often among groups (the C++ maintainers, 
people who know a lot about reload, etc.) that are at least two orders 
of magnitude smaller than the group as a whole.  Even the SC doesn't 
always get consensus; we vote, and often have split votes.

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

Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| 
| >Making regular bug-fix releases at regularly spaced times makes good
| >sense to me.  What I'm unclear about is what we want for the *major*
| >releases.  Do we just want them every 6 months?  Do we drive it by
| >quality?  If by quality, what are the quality criteria?  I suspect
| >
| We cannot drive it purely by quality, since we will never get quality
| unless we decide that we're going to make a release.  The level of
| bug-fixing activity goes up steeply as we approach a release: people
| start to fear that "their" platform/language/etc. will not work well.
| That's why we use a combination: drive by time, and then push for
| quality towards that date.
| 
| >| they can lead to lower quality, as more and more changes go in,
| >| sometimes without corresponding problem-solving efforts.  I also don't
| >| think that "wait until it is ready" is a practical method for a
| >| project this big with this much change and with so much
| >| inter-dependency between components.
| >
| >Again, I agree.  However, because the project is that big, I believe
| >branching  proposals should meet consensus among developers.
| >
| In contrast, I don't see consensus as achievable in this group.  We

That says a lot.

-- Gaby

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Gabriel Dos Reis wrote:

>Making regular bug-fix releases at regularly spaced times makes good
>sense to me.  What I'm unclear about is what we want for the *major*
>releases.  Do we just want them every 6 months?  Do we drive it by
>quality?  If by quality, what are the quality criteria?  I suspect
>  
>
We cannot drive it purely by quality, since we will never get quality 
unless we decide that we're going to make a release.  The level of 
bug-fixing activity goes up steeply as we approach a release: people 
start to fear that "their" platform/language/etc. will not work well.  
That's why we use a combination: drive by time, and then push for 
quality towards that date.

>| they can lead to lower quality, as more and more changes go in,
>| sometimes without corresponding problem-solving efforts.  I also don't
>| think that "wait until it is ready" is a practical method for a
>| project this big with this much change and with so much
>| inter-dependency between components.
>
>Again, I agree.  However, because the project is that big, I believe
>branching  proposals should meet consensus among developers.
>  
>
In contrast, I don't see consensus as achievable in this group.  We 
barely get consensus on technical issues, let alone on priorities.

Instead, I see my job as to take input, ponder it, consult with people, 
and make decisions.  The decisions I made about 3.5 were made with lots 
of input from lots of people -- developers, users, and other 
stakeholders -- and informed by discussions with people going back as 
far as the summit in Ottawa.  I don't expect everyone to be 100% happy 
about my decisions; I only hope to do a good enough job of being fair 
and reasonable that people respect them.

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

Re: GCC 3.5 Status (2004-08-29)

[Nathanael Nerode]

>For everything not explicitly mentioned below, Stage 3 will begin
>September 5th as announced.

I notice that the, uh, "project" to get Ada bootstrapping (Kenner, when can
we expect this?) is not listed.  These changes will presumably be accepted
in stage 3?

However, I'm beginning to worry that Ada is going to delay the release
of GCC 3.5 substantially if it's not bootstrapping soon, because the long
period without Ada bootstrapping is likely to lead to bug discoveries when
Ada is revived from the dead.

Is Ada functioning a requirement for the release?  If so it seems a moderately
bad idea to go into stage 3 with it totally busted.

-- 
This space intentionally left blank.

Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| >What are our release criteria?  Sorry to ask the trivial, but it is
| >because I'm unclear about what we're after.
| >
| There is no single answer.  The GNU/Linux distro vendors want things,
| embedded people want things, hardware vendors what things, and other
| people want  things.  And, everyone wants the release schedule to line
| up with their own personal and/or organizational schedules.
| 
| As the RM, I want releases that are both timely and of high-quality.
| These two things cannot be entirely traded against each other: longer
| release cycles do not necessarily lead to higher quality.  In fact,

If you're saying that having a release cycle of ten years is not
automatically going make the release of good quality, I can only agree
with you.

Making regular bug-fix releases at regularly spaced times makes good
sense to me.  What I'm unclear about is what we want for the *major*
releases.  Do we just want them every 6 months?  Do we drive it by
quality?  If by quality, what are the quality criteria?  I suspect
that question is harder than the previous to answer because we don't
seem to have metrics that throw numbers at us.  I don't think we have
answers for time and quality combined; or at least I'm just unable to
find where we're consistently applying them.

| they can lead to lower quality, as more and more changes go in,
| sometimes without corresponding problem-solving efforts.  I also don't
| think that "wait until it is ready" is a practical method for a
| project this big with this much change and with so much
| inter-dependency between components.

Again, I agree.  However, because the project is that big, I believe
branching  proposals should meet consensus among developers.

| I think that GCC 3.5 is going to be a good release.  I also think that
| the first release with major new technology (tree-ssa is easily the
| biggest change to GCC in a decade) is going to have dot-zero
| properties: it won't work perfectly for all people all of the time.
| Since everyone else (including Oracle, Microsoft, Red Hat, etc.) has
| that problem with huge revisions, I think we will have problems too --
| independently of exactly when we do a release.  Oh, well.

The issue is not whether we're going to have dot zero problems or
not.  But what is knowingly and with consensus decided to be included
in that set.

I'm not trying to make your job harder -- the RM position is alrady
hard enough.

-- Gaby

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Gabriel Dos Reis wrote:

>"Giovanni Bajo" <giovannibajo@libero.it> writes:
>
>| Mark Mitchell wrote:
>| 
>| > If people want to put GCC 3.5 off until next
>| > June, and SC approves, it's OK with me.
>| 
>| I think this should be seriously considered. Given the large number of
>| incomplete projects (partly merged like the vectorizer, or being worked on
>| offline), and the fact that we are currently maintaing *two* stable release
>| branches, I don't think we should *rush* at releasing 3.5. Waiting another 6
>| months could be a good compromise. What do others think about this?
>
>I agree with your general sentiment.  We rushed to release 3.4.0
>because it was thought 3.5.0 would bring the bonus of changes
>happening in 3.4.0.  
>
I disagree with that analysis.  GCC 3.4.0 was a pretty good release, as 
evidence by the fact that the major distros have moved to it or are 
moving towards it.  Certainly, it's the best C++ release we've ever had, 
and the generated code is better than previous releases.  In hindsight, 
the c-decl stuff was something of a mess, but it's hard to be perfect.

>What are our release criteria?  Sorry to ask the trivial, but it is
>because I'm unclear about what we're after.
>  
>
There is no single answer.  The GNU/Linux distro vendors want things, 
embedded people want things, hardware vendors what things, and other 
people want  things.  And, everyone wants the release schedule to line 
up with their own personal and/or organizational schedules.

As the RM, I want releases that are both timely and of high-quality.  
These two things cannot be entirely traded against each other: longer 
release cycles do not necessarily lead to higher quality.  In fact, they 
can lead to lower quality, as more and more changes go in, sometimes 
without corresponding problem-solving efforts.  I also don't think that 
"wait until it is ready" is a practical method for a project this big 
with this much change and with so much inter-dependency between components.

I think that GCC 3.5 is going to be a good release.  I also think that 
the first release with major new technology (tree-ssa is easily the 
biggest change to GCC in a decade) is going to have dot-zero properties: 
it won't work perfectly for all people all of the time.  Since everyone 
else (including Oracle, Microsoft, Red Hat, etc.) has that problem with 
huge revisions, I think we will have problems too -- independently of 
exactly when we do a release.  Oh, well.

I would like to get the other improvements in GCC 3.5.0 (new target 
support, etc.) released and I also think it would be very good for us to 
focus for a while on fixing bugs rather than adding features.

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

Re: GCC 3.5 Status (2004-08-29)

[Gabriel Dos Reis]

"Giovanni Bajo" <giovannibajo@libero.it> writes:

| Mark Mitchell wrote:
| 
| > If people want to put GCC 3.5 off until next
| > June, and SC approves, it's OK with me.
| 
| I think this should be seriously considered. Given the large number of
| incomplete projects (partly merged like the vectorizer, or being worked on
| offline), and the fact that we are currently maintaing *two* stable release
| branches, I don't think we should *rush* at releasing 3.5. Waiting another 6
| months could be a good compromise. What do others think about this?

I agree with your general sentiment.  We rushed to release 3.4.0
because it was thought 3.5.0 would bring the bonus of changes
happening in 3.4.0.  As a matter of fact, we now get another set of
new things whose bonuses are promised for the future.
What are our release criteria?  Sorry to ask the trivial, but it is
because I'm unclear about what we're after.

-- Gaby

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Daniel Berlin wrote:

>On Sun, 2004-08-29 at 16:17 -0700, Mark Mitchell wrote:
>
>Just a note, I pasted your email into the wiki
>(www.dberlin.org/gccwiki), and edited it slightly (mainly changing []'s
>to ()'s so they don't show up as link, and making the data second level
>list elements), so that we have a nice, editable html page you can use
>to refer to.
>  
>
Thanks!

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

Re: GCC 3.5 Status (2004-08-29)

[Matt Austern]

On Aug 29, 2004, at 7:00 PM, Giovanni Bajo wrote:

> Mark Mitchell wrote:
>
>> If people want to put GCC 3.5 off until next
>> June, and SC approves, it's OK with me.
>
> I think this should be seriously considered. Given the large number of
> incomplete projects (partly merged like the vectorizer, or being 
> worked on
> offline), and the fact that we are currently maintaing *two* stable 
> release
> branches, I don't think we should *rush* at releasing 3.5. Waiting 
> another 6
> months could be a good compromise. What do others think about this?
>
>> Otherwise, I think we
>> proceed, and accept that the release will be useful to some people
>> and less useful to others.  (It will, for example, be useful to
>> people who need support for new targets, or want gfortran, or want
>> faster non-optimizing compile times, which we are now seeing for some
>> C++ programs.)
>
> As for C++ programs, I would like to remember that when tree-ssa was 
> merged,
> there were big C++ compile time issues at -O0, which used to be in the 
> merge
> requirement list, but were not met. There was agreement that these 
> would be
> tackled after the merge, possibly by running a couple of cleanup 
> optimization
> passes (DCE/CCP). I never heard of this project again since then, and 
> the
> issues seems to have been forgotten. I am sure I am not the only one 
> who cares
> about C++ compilation times at -O0: we got substantially better with 
> 3.4 (even
> wrt 2.95), but now we are regressing way too much.

You are not the only person who cares about C++ compilation times at 
-O0.  This is a major concern for Apple, and I expect that improving 
C++ -O0 compilation time will be my primary activity for some time.  I 
don't think the current status it too awful, actually, but we do still 
have a way to go.

Do you have any suggestions for improving -O0 compile speed?

			--Matt

Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

On Sun, 2004-08-29 at 16:17 -0700, Mark Mitchell wrote:

Just a note, I pasted your email into the wiki
(www.dberlin.org/gccwiki), and edited it slightly (mainly changing []'s
to ()'s so they don't show up as link, and making the data second level
list elements), so that we have a nice, editable html page you can use
to refer to.

http://www.dberlin.org/gccwiki/index.php/What%20will%20be%20in%203.5


It's also linked from the homepage.
People who add information about their projects on this list to the
wiki, please make sure you add a link from this page.

Re: GCC 3.5 Status (2004-08-29)

[Giovanni Bajo]

Mark Mitchell wrote:

> If people want to put GCC 3.5 off until next
> June, and SC approves, it's OK with me.

I think this should be seriously considered. Given the large number of
incomplete projects (partly merged like the vectorizer, or being worked on
offline), and the fact that we are currently maintaing *two* stable release
branches, I don't think we should *rush* at releasing 3.5. Waiting another 6
months could be a good compromise. What do others think about this?

> Otherwise, I think we
> proceed, and accept that the release will be useful to some people
> and less useful to others.  (It will, for example, be useful to
> people who need support for new targets, or want gfortran, or want
> faster non-optimizing compile times, which we are now seeing for some
> C++ programs.)

As for C++ programs, I would like to remember that when tree-ssa was merged,
there were big C++ compile time issues at -O0, which used to be in the merge
requirement list, but were not met. There was agreement that these would be
tackled after the merge, possibly by running a couple of cleanup optimization
passes (DCE/CCP). I never heard of this project again since then, and the
issues seems to have been forgotten. I am sure I am not the only one who cares
about C++ compilation times at -O0: we got substantially better with 3.4 (even
wrt 2.95), but now we are regressing way too much.

IMHO, bugs like PR 15678 (C) and PR 13776 (C++) should be showstoppers for
branching 3.5.

Giovanni Bajo

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Daniel Berlin wrote:

>>> I am confident that there
>>>are alternatives that, while perhaps less comprehensive, get enough of
>>>the common cases to achieve most of the benefits.
>>>      
>>>
>>What is your confidence based on?  What common cases?  Did Dan tell you
>>about the issues that he's fighting?  No "less comprehensive" solution
>>exists that will not run into the exact same problems.
>>
>>    
>>
>
>I didn't tell him about the issues i'm fighting, so he's probably just
>stating the typical result, ie "It takes less time to get the common
>cases than it does to get all the cases".
>
>Of course, the issues i'm dealing with are things that were punted on
>earlier in the design of tree-ssa, because they were either hard to get
>right, we didn't have time then, etc.
>
>Let me give an example issue from an email i sent to diego and richard,
>as a motivating example.
>  
>
Yes, there's some design work to be done.  That's why I believed your 
estimate about how long it will take, and why parallelizing the work 
will only help so much: you still have to agree on a design up front.

I still think there are likely to be expedient hacks that get you a lot 
of the win.  Note that the RTL optimizers didn't know about fields at 
all until recently (3.4?).  So, perhaps we can deal with the 
compile-time issue by accepting somewhat inferior generated code.  
Perhaps you can wait until SRA runs, and then just DTRT for objects that 
get SRA'd.  I don't have the answer; I'm just saying that there's likely 
to be one out there somewhere.  GCC got by for years with exactly this 
kind of solution, and actually managed to generate relatively decent 
code relatively often.

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

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Andrew Pinski wrote:

>
> On Aug 29, 2004, at 5:53 PM, Mark Mitchell wrote:
>
>> Maintaining compilation speed was a precondition set by the SC for 
>> the tree-ssa merge.  If that condition was not met, then perhaps the 
>> merge should not have been performed.  The fact that it was probably 
>> indicates that people weren't too worried about these compile-time 
>> effects.
>
>
>
> There has been a couple of cases where compile time has actually speed up
> a huge amount even with the new optimization so it was no a clear cut if
> we should not merge or not.

I am not criticizing the decision to merge.  In fact, I am not at all 
surprised that it is faster sometimes and slower other times: the same 
is true of the generated code.  (There are also some new bugs, and some 
old bugs fixed, and...)  The tree-ssa changes are a huge perturbation 
and, as such, it's hard to make absolute "it's better" or "it's worse" 
statements.

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

Re: GCC 3.5 Status (2004-08-29)

[Andrew Pinski]

On Aug 29, 2004, at 5:53 PM, Mark Mitchell wrote:

> Maintaining compilation speed was a precondition set by the SC for the 
> tree-ssa merge.  If that condition was not met, then perhaps the merge 
> should not have been performed.  The fact that it was probably 
> indicates that people weren't too worried about these compile-time 
> effects.


There has been a couple of cases where compile time has actually speed 
up
a huge amount even with the new optimization so it was no a clear cut if
we should not merge or not.

I should note that the bootstrap time feels longer but I could be 
imagining
things.


-- Pinski

Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

> >  I am confident that there
> > are alternatives that, while perhaps less comprehensive, get enough of
> > the common cases to achieve most of the benefits.
> 
> What is your confidence based on?  What common cases?  Did Dan tell you
> about the issues that he's fighting?  No "less comprehensive" solution
> exists that will not run into the exact same problems.
> 

I didn't tell him about the issues i'm fighting, so he's probably just
stating the typical result, ie "It takes less time to get the common
cases than it does to get all the cases".

Of course, the issues i'm dealing with are things that were punted on
earlier in the design of tree-ssa, because they were either hard to get
right, we didn't have time then, etc.

Let me give an example issue from an email i sent to diego and richard,
as a motivating example.

In our current scheme of things,

x = a.f
c = a.e
a.e = 5
c = a.f

becomes

VUSE (a_1)
x_2 = a.f

VUSE (a_1)
c_3 = a.e

a_4 = V_MAY_DEF (a_1)
a.e = 5

VUSE (a_4)
c_5 = a.f

As you can see, this type of VUSE should actually be called PARTIAL_USE
or something (it was the first use of vuse, before they were actually
used for memory operands, so i blame diego for not renaming it, unless
i'm misremembering and it was introduced at the same time as memory
operands).

Knowing that a.e doesn't actually kill a.f is the *easy* part.
It's representing this that is tricky.

You can't get rid of the VUSE of a, because it's still really a partial
use.  You can't simply change the V_MAY_DEF, because that will screw up
the later partial uses.  Unless we start to talk about fitting something
radically different into our scheme, you need to do something like add
an extra set of vuses so that it becomes:

VUSE (a_1)
VUSE (a.f_1)
x_2 = a.f

VUSE (a_1)
VUSE (a.e_1)
c_3 = a.e

a.e_2 = V_MAY_DEF (a.e_1)
a.e = 5

VUSE (a_1)
VUSE (a.f_1)
c_5 = a.f


This gives you the result you want.  But of course, we don't allow
component_refs in SSA_NAMES right now. You can't simply use field_decls,
because of compatible struct problems.

Do we want SSA_NAMES of component_refs here, or do we want just offset +
size, and then let the renamer do the work of figuring out the versions
to assign as a result:

IE

VUSE (a_1, 0, 4)
x_2 = a.f

VUSE (a_1, 4, 8)
c_3 = a.e

a_2 = V_MAY_DEF (a_1, 4, 8)
a.e = 5

VUSE (a_1, 0, 4)
c_5 = a.f

(IE let it figure out that we can still reuse a_1 here, because it
hasn't been def'd).

Or do we want something else entirely not involving vuses?

The issue of "p->a" and "p->b" aliasing hand a[0] vs a[1] aliasing have
similar unresolved design issues, like what do we put in the alias
bitmaps (IE pt_vars), since none of these things have uids that are in
the same namespace as variables. Or do i just ignore the existing alias
bitmaps -> may alias conversion, and just add component_refs to the
alias varrays directly, and maximally share the component refs.  Or
something else not involving component refs?  

This is the stuff i'm counting on taking the most time.
--Dan

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Steven Bosscher wrote:

>On Monday 30 August 2004 02:03, Mark Mitchell wrote:
>  
>
>>Steven Bosscher wrote:
>>    
>>
>>>On Monday 30 August 2004 01:17, Mark Mitchell wrote:
>>>      
>>>
>>>>The following changes will be postponed until GCC 3.6.  These changes
>>>>either provide too little benefit, are too risky, or will take too
>>>>much time to complete.
>>>>
>>>>* Aliasing improvements for structure fields [Berlin]
>>>>        
>>>>
>>>But you should
>>>realize that this analysis is absolutely critical if GCC 3.5 is going
>>>to perform reasonably well.
>>>      
>>>
>>I am not convinced of this statement.
>>
>>First, the compiler speed argument mostly affects optimizing
>>compilations, where compile-times are much less critical than
>>non-optimizing compilations.  I'm sure that people will want to argue
>>this point, but I've been talking with customers for a decade and the
>>ones concerned about compile-times are almost always willing to have
>>optimizing compilation take longer.
>>    
>>
>
>Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
>just about every project using GCC complaining about how GCC gets slower
>with each release?
>  
>
Obviously, this is not ideal.  However, we have few practical 
alternatives.  I am not convinced that any further delay will get us 
better results.  I do not see a broad committment to improving 
compile-time speed when optimizing: in fact, I got zero proposals from 
people planning to work specifically on that issue. 

We have no way of knowing for sure that Dan's work will help here 
either, or how many follow-on effects there will be.  If Dan's work does 
what we expect, then we can turn off some RTL optimizers.  That will 
help, but I doubt it will help by a factor of two.  We've been looking 
at compile-time issues a lot lately, and generally these turn out to be 
pretty subtle.  Since Dan's work requires touching lots of code, it will 
introduce bugs.  They will have to be fixed.  We will likely uncover 
other latent bugs as a result of Dan's code making things more aggressive.

Maintaining compilation speed was a precondition set by the SC for the 
tree-ssa merge.  If that condition was not met, then perhaps the merge 
should not have been performed.  The fact that it was probably indicates 
that people weren't too worried about these compile-time effects.

I continue to think it will take at least another several months to 
really get to the point where tree-ssa is unambiguously better 
(consistently better code, consistently better compile-times, fewer 
bugs) than GCC 3.4.  If people want to put GCC 3.5 off until next June, 
and SC approves, it's OK with me.  Otherwise, I think we proceed, and 
accept that the release will be useful to some people and less useful to 
others.  (It will, for example, be useful to people who need support for 
new targets, or want gfortran, or want faster non-optimizing compile 
times, which we are now seeing for some C++ programs.)  There are always 
people who declare any given release to be "totally broken".

>>the common cases to achieve most of the benefits.
>>    
>>
>
>What is your confidence based on?  What common cases?  Did Dan tell you
>about the issues that he's fighting?  No "less comprehensive" solution
>exists that will not run into the exact same problems.
>  
>
My confidence is based on the fact that there are generally such 
solutions to most such problems in software engineering.  Perhaps this 
is the very rare case where there is no acceptable short-term solution 
that gets much of the win, but I'd be surprised.

>>Third, if this change is so vital, then we should be willing to drop
>>some other changes in favor of this one, so that people can work with
>>Dan to finish this one.  Why don't you suggest some changes that are
>>already on the list that you'd be willing to give up?
>>    
>>
>
>The things I currently work on that I would drop right away:
>* Edges-in-vectors conversion [Elliston]
>* Tree-based profile-directed feedback [Hubicka]
>
>Things that I think are not as important as beter AA:
>* Linear loop transforms [Berlin]
>* Variable expansion optimization [Eres]
>* Tree-based branch prediction [Hubicka]
>...and probably other stuff, but these are the only ones from which I
>think we reasonably expect that they would help Dan (hey, is he on that
>list?!) with his AA work.
>
That's roughly the same list I would have come up with, with the 
exception of Elliston's changes, which I think are important precisely 
because they will likely reduce memory usage and help compile times.  If 
Dan, Jan, and Revital are willing to abandon their other projects and 
will commit to working with you on aliasing, and together, you think 
that you can get things done much more quickly, let me know.  (There is 
probably not much to be done for linear loop transforms, since Dan 
indicates that it is already submitted.)  I am willing to trade.

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

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 02:03, Mark Mitchell wrote:
> Steven Bosscher wrote:
> >On Monday 30 August 2004 01:17, Mark Mitchell wrote:
> >>The following changes will be postponed until GCC 3.6.  These changes
> >>either provide too little benefit, are too risky, or will take too
> >>much time to complete.
> >>
> >>* Aliasing improvements for structure fields [Berlin]
> >
> >But you should
> >realize that this analysis is absolutely critical if GCC 3.5 is going
> >to perform reasonably well.
>
> I am not convinced of this statement.
>
> First, the compiler speed argument mostly affects optimizing
> compilations, where compile-times are much less critical than
> non-optimizing compilations.  I'm sure that people will want to argue
> this point, but I've been talking with customers for a decade and the
> ones concerned about compile-times are almost always willing to have
> optimizing compilation take longer.

Hmm, let's argue.  So you think 25-100% slowdown is justifyable despite
just about every project using GCC complaining about how GCC gets slower
with each release?

Are you aware of the compile time comparisons from Diego?
http://people.redhat.com/dnovillo/spec2000/gcc/individual-build-secs_elapsed.html

As you can see, we are between 25 and 100% slower on almost _every_ SPEC
benchmark that compiled with older GCCs as well.  Only eon (C++) builds
faster, and ammp is about the same as GCC 3.4.
For most benchmarks we need 2.5 - 3 times as long as icc - which happens
to also outperform GCC on just about every benchmark.

People may be willing to accept a slower compiler when optimizing, but 
by now even I am wondering if I should just switch to a faster compiler
that also produces better code on this very popular target  ;-)


> Second, Dan said it will take 2-3 months to complete this work.  That's
> a lot of time, and indicates a big project.

Dan has so far been entirely on his own.  Note that his alias solver is
as good as ready, it just needs to be integrated in CC.  I don't know how
much work it would take, but apparently a lot.  Perhaps if more people
could help out (which is actually already happening), this doesn't have
to take 3 months.  Dan/Diego/RTH can probably come up with more comments
on this.


>  I am confident that there
> are alternatives that, while perhaps less comprehensive, get enough of
> the common cases to achieve most of the benefits.

What is your confidence based on?  What common cases?  Did Dan tell you
about the issues that he's fighting?  No "less comprehensive" solution
exists that will not run into the exact same problems.


> Third, if this change is so vital, then we should be willing to drop
> some other changes in favor of this one, so that people can work with
> Dan to finish this one.  Why don't you suggest some changes that are
> already on the list that you'd be willing to give up?

The things I currently work on that I would drop right away:
* Edges-in-vectors conversion [Elliston]
* Tree-based profile-directed feedback [Hubicka]

Things that I think are not as important as beter AA:
* Linear loop transforms [Berlin]
* Variable expansion optimization [Eres]
* Tree-based branch prediction [Hubicka]
...and probably other stuff, but these are the only ones from which I
think we reasonably expect that they would help Dan (hey, is he on that
list?!) with his AA work.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Daniel Berlin]

On Sun, 29 Aug 2004, Mark Mitchell wrote:

> Andrew Pinski wrote:
>
>> 
>> On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:
>> 
>>> * Aliasing improvements for structure fields [Berlin]
>> 
>> 
>> Actually without this, we will produce wrong code so I think this one
>> should be rethought about and not delaying it until 3.6.
>
> I think you are talking about something different.
>
> In particular, this is work that Dan said he could not complete for several 
> months.  I fail to  believe that PR 15262 cannot be fixed without adding lots 
> of new optimization infrastructure.

This is correct (the time estimate).
Being realistic, without help, it will be several months before it can be 
complete (IE when it's not causing regressions and all latent bugs are 
fixed).Of course, if it  doesn't expose any latent bugs, causes no 
testsuite failures, a good design for how to integrate the information 
is quickly agreed upon, and others were to help out with the integrating 
(there are a few pieces that should be able to be parallelized once a 
design is agreed upon), the time could be significantly shortened.

A lot of that  time is going to be spent in the  infrastructure necessary 
to make this useful, which encompasses a lot of 
the low hanging fruit by definition (simply saying that a store to a.b 
doesn't kill the entire value of a).
In fact, this is actually where most of these months is going to be spent 
(and fixing latent bugs/problems that pop up as a result).

Actually writing something that produces the alias information we want 
(knowing whether p->a and p->b alias, knowing whether x[0] and x[1] 
alias), and  making sure it gives correct 
results for corner cases, is what i saw as the easy part, at least for me.
This is, in fact, done, bootstrapping, and passes all it's internal 
checking during bootstrap.  I've tested it on some wonky cases, and it 
produces what appear to be correct results.
I can post it tommorrow if people want to see it.
There are improvements that could be made to the results, of 
course, and TODO's, but none that were so important as the basic 
information.

Using the information, of course, is the part that is going to require the 
architectural changes, design work, etc.

I just sent some email to Diego and RTH this morning to see if they had 
any thoughts about what to do here, along with a somewhat simplistic idea 
of how to solve the "a.b vs a.c" issue.

I'll note that a design is agreed upon for the "make stores 
to a.b not kill a.c" issue, if others were to help implement it, we could 
probably tackle it before 3.5 (IE in the next month), and i would happily 
do the rest of the work alone (if need be) for "p->a vs p->b, a[0] vs 
a[1]", etc

--Dan

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Steven Bosscher wrote:

>On Monday 30 August 2004 01:17, Mark Mitchell wrote:
>  
>
>>The following changes will be postponed until GCC 3.6.  These changes
>>either provide too little benefit, are too risky, or will take too
>>much time to complete.
>>
>>* Aliasing improvements for structure fields [Berlin]
>>
>>    
>>
>But you should
>realize that this analysis is absolutely critical if GCC 3.5 is going
>to perform reasonably well.
>  
>
I am not convinced of this statement. 

First, the compiler speed argument mostly affects optimizing 
compilations, where compile-times are much less critical than 
non-optimizing compilations.  I'm sure that people will want to argue 
this point, but I've been talking with customers for a decade and the 
ones concerned about compile-times are almost always willing to have 
optimizing compilation take longer.

Second, Dan said it will take 2-3 months to complete this work.  That's 
a lot of time, and indicates a big project.  I am confident that there 
are alternatives that, while perhaps less comprehensive, get enough of 
the common cases to achieve most of the benefits.

Third, if this change is so vital, then we should be willing to drop 
some other changes in favor of this one, so that people can work with 
Dan to finish this one.  Why don't you suggest some changes that are 
already on the list that you'd be willing to give up?

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

Re: GCC 3.5 Status (2004-08-29)

[Mark Mitchell]

Andrew Pinski wrote:

>
> On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:
>
>> * Aliasing improvements for structure fields [Berlin]
>
>
> Actually without this, we will produce wrong code so I think this one
> should be rethought about and not delaying it until 3.6.

I think you are talking about something different.

In particular, this is work that Dan said he could not complete for 
several months.  I fail to  believe that PR 15262 cannot be fixed 
without adding lots of new optimization infrastructure.

>> * If-conversion and vectorization of conditional code [Patel]
>
>
> Part of this one has been submitted already so it should be able to 
> get into
> 3.5.0 without the trouble and it is already on the apple-ppc-branch 
> and the
> lno branch.
> <http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02291.html>

If-conversion has been submitted.  There are non-trivial issues with the 
patch according to Richard.  If this gets done before Septemberr 5th, I 
don't object.  Otherwise, we don't need this before GCC 3.5.

>> * Analysis of usage of compilation unit static variables and removal
>>   of spurious clobbering vdef based on the information [Zadeck]
>
> This has been submitted already with almost no context review and no
> approval ....
> <http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02187.html>

Yes, I hope this will get finished.

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

Re: GCC 3.5 Status (2004-08-29)

[Steven Bosscher]

On Monday 30 August 2004 01:17, Mark Mitchell wrote:
> The following changes will be postponed until GCC 3.6.  These changes
> either provide too little benefit, are too risky, or will take too
> much time to complete.
> 
> * Aliasing improvements for structure fields [Berlin]

I believe this is a big mistake.  Yes I know this may or may not be
ready on time according to _your_ schedule as the RM.  But you should
realize that this analysis is absolutely critical if GCC 3.5 is going
to perform reasonably well.

I have done extensive testing of the effect of some RTL passes on GCC
bootstraps over the past few weeks. One of my findings is that:

1) almost all opportunities for jump threading we still do on RTL, and
2) almost all (like ~99%) store motion opportunities,

only happen because we miss alias information for fields at the tree
level.  We *need* this alias analysis to be able to simplify or remove
some RTL passes.  In the end, that is the *only* way to retrieve the
compiler speed we have lost with ~60 new passes we do since tree-ssa
was merged.

[ That doesn't even take into account the extra optimizations we can
  do on trees with this information.  ]

This new optimization frame work we have is fun and cool and gread and
all.  But I don't believe GCC 3.5 should be released without alias
analysis that is at least capable of catching as much as what we catch
now on RTL.

Gr.
Steven

Re: GCC 3.5 Status (2004-08-29)

[Andrew Pinski]

On Aug 29, 2004, at 4:17 PM, Mark Mitchell wrote:

> * Aliasing improvements for structure fields [Berlin]

Actually without this, we will produce wrong code so I think this one
should be rethought about and not delaying it until 3.6.

See PR 15262.

> * If-conversion and vectorization of conditional code [Patel]

Part of this one has been submitted already so it should be able to get 
into
3.5.0 without the trouble and it is already on the apple-ppc-branch and 
the
lno branch.
<http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02291.html>

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


This has been submitted already with almost no context review and no
approval ....
<http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02187.html>

Thanks,
Andrew Pinski


PS I should also note Ada still does not build at least at the last know
report, we got from Kenner and other Ada Core people.

GCC 3.5 Status (2004-08-29)

[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: 7404 bytes --]

Asking for project submissions was certainly useful.  I got 45 such
submissions.  Henceforth, I plan to request these submissions much
earlier in the release process.

Below is a list of all of the projects received.  There are dates with
some of the projects.  Those are deliver-by dates.  If your project is
not submitted by that point, with appropriate testing, etc., we're
going to pass on it.  Some of the dates are earlier than the
submitter's estimated delivery-by dates.  I know these dates may not
be achievable.  There's no obligation on the submitter to try to meet
these dates -- but if you don't, we'll move on without you.  If the
project is submitted, but not reviewed, by that date, we'll try to get
it incorporated.  Of course, just because your project is submitted by
the deliver-by date doesn't ensure acceptance; you must still
convinvce the appropriate maintainers that your change is worthwhile.

For everything not explicitly mentioned below, Stage 3 will begin
September 5th as announced.  We'll fully enter Stage 3 on September
26th, which is one week after the latest deliver-by date below, to
give us some time to review things submitted by the September 19th
dates.  The reason that other "safe" Stage 2-ish changes will not be
accepted between September 5th and October 1st is that (a) history has
shown that such changes are often not as safe as submitters think, and
(b) there are lots of bugs to fix.  Furthermore, I believe it to be
the case that, in the timeframe in question, bigger performance wins
can be had by tuning and improving the existing code than by adding
new optimizations.

We will include projects marked for postponement until GCC 3.6 below
if they have already been submitted or make it in before September
5th, so as to be consistent with earlier announcements.

If you disagree with my decisions, feel free to send me a message
explaining why you think that the decision was inappropriate.  I will
consider your position, but you will have to be convincing in order to
change my mind.  To be convincing, make sure you quantify the win: it
you want me to believe that your optimization is worthwhile tell me
how much it improves a well-known benchmark.

-------------
Cleanups, etc.
-------------

There were a few submissions that are cleanups, or infrastructure
improvements, on which nothing else depends, and which -- according to
the submitters themselves -- do not bring substantial user-visible
improvements.  Those will not be accepted past the previously
announced Stage 3 cutoff date: September 5th.  These include:

* Immediate use integration [MacLeod] 

* Top-level bootstrap [Bonzini/Nerode]

* Automatic dependency for GCC builds [Weinberg]

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

These changes are all good -- but get them in before September 5th, or
hold on to them until GCC 3.6.

--------------------------------
Target/language-specific changes
--------------------------------

As a general rule, I'm going to delegate target-specific and
language-specific changes to the discretion of the appropriate
maintainers, at least until we make the release branch, and perhaps
longer.  So, for example, the Java ABI rework can go in during Stage
3, if the Java maintainers think that's OK, and the MIPS paired-float
work can go in if the MIPS maintainers think it's OK.  Maintainers,
please exercise good judgement here, and err on the side of caution.
If your port/language gets all messed up, I'll be very hesitant to
delegate to you in future.  I'm not delgating similar responsibilities
for common code (including optimizations) because the consequences of
changes there are much more far-reaching.

This delgation rule applies to the following language-specific
changes:

* Member class template as template friend (PR13495) [Lerdsuwanakij]

* GCJ BC ABI [Haley/McKinlay/Tromey]

* C90 [Myers]

* Objective-C++ [Laski]

* Add "Class <protocol>" support to the ObjC frontend [Ayers]

In addition, the SC has promised Zem that we wil get Objective-C++
into GCC 3.5.  Therefore, we will not release without Objective-C++,
unless something seems to have gone horribly awry.

This delgation rule also applies to the following target-specific
changes:

* PowerPC GNU/Linux dot-smybol removal [Modra]

* MIPS paired single support [Wilson]

* PA long conditional branches [Anglin]

* PA GNU/Linux TLS [Anglin]

* PA HP-UX Ada [Anglin]

* 64-bit PA HP-UX shared libgcc support [Anglin]

* Windows TLS/weak/shared/versioning support [LaFramboise]

This delegation rule does *not* apply to the following changes, as I
consider them to have too high a risk/reward ratio, and they will
therefore be postponed until GCC 3.6:

* 64-bit PA HP-UX DWARF2 Exceptions [Anglin]

* PA HP frame layout [Anglin]

* IA64 floating-point model [Weinberg]

* HP-UX __fpreg support [Weinberg]

* HP-UX #pragma _USE_SF support [Weinberg]

* IA64 division/sqrt scheduling improvements [Weinberg]

If these get done, and look very solid, and everyone wants them, I'll
reconsider.

-------------------------
Compile-Time Improvements
-------------------------

There were three submissions relating primarily to compile-time
improvements.  Since this has been a persistent problem, we'll allow
these changes for GCC 3.5 -- if they can get finished quickly enough.

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

  September 19

* Edges-in-vectors conversion [Elliston]

  September 19

* General compile-time performance improvements [Weinberg]

  This project is a catch-all.  We will decide these on a per-change
  basis.  Compile-time performance is a major issue.  As in previous
  Stage 3s, and even on release branches, these changes will be OK,
  with appropriate maintainer approval -- but more localized, smaller
  changes will of course be favored over bigger changes.

--------------------
Optimization Changes
--------------------

There are a ton of these: a lot of people are working hard on a lot of
really interesting projects.  What I've done with these is selected
those that I think have the best risk/reward/timeliness tradeoffs.

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

  September 12

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

  September 19

* Vectorize unknown-loop-bound support [Golovanevsky]

  September 12

* Vectorizer peeling-for-alignment support [Golovanevsky]

  September 19

* Vectorizer additional data-references support [Rosen]

  September 19

* Linear loop transforms [Berlin]

  September 12

* Variable expansion optimization [Eres]

  September 12

* LNO branch merge [Dvorak]

  September 19

* Tree-based branch prediction [Hubicka]

  September 5 

* Tree-based profile-directed feedback [Hubicka]

  September 12

The following changes will be postponed until GCC 3.6.  These changes
either provide too little benefit, are too risky, or will take too
much time to complete.

* Tree-based coverage [Hubicka]

* Aliasing improvements for structure fields [Berlin]

* Value range propagation [Novillo]

* CFG-based inliner [Hastings]

* Vectorizer misaligned-loads support [Naishlos]

* Vectorizer pattern recognition support [Naishlos]

* If-conversion and vectorization of conditional code [Patel]

* SMS improvements [Hagog, Markovitch]