Diego Novillo appointed middle-end maintainer and non-algorithmic GWP

Diego Novillo appointed middle-end maintainer and non-algorithmic GWP

[David Edelsohn]

	I am pleased to announce that the GCC Steering Committee has
promoted Diego Novillo to middle-end maintainer and appointed him
non-algorithmic Blanket/Global Write Privileges maintainer.

	Please join me in congratulating Diego on his
new role.  Please update your listings in the MAINTAINERS file.

Happy hacking!
David

Re: Diego Novillo appointed middle-end maintainer and non-algorithmic GWP

[Diego Novillo]

On 6/14/07 6:37 AM, David Edelsohn wrote:

> Please update your listings in the MAINTAINERS file.

Thanks.  Committed.

	* MAINTAINERS: Add self as middle-end maintainer and
        non-algorithmic global write maintainer.

Index: MAINTAINERS
===================================================================
--- MAINTAINERS (revision 125706)
+++ MAINTAINERS (working copy)
@@ -192,6 +192,7 @@
 testsuite              Janis Johnson           janis187@us.ibm.com
 middle-end             Roger Sayle             roger@eyesopen.com
 middle-end             Ian Lance Taylor        ian@airs.com
+middle-end             Diego Novillo           dnovillo@google.com
 tree-ssa               Diego Novillo           dnovillo@google.com
 tree-ssa               Andrew MacLeod          amacleod@redhat.com
 PRE                    Daniel Berlin           dberlin@dberlin.org
@@ -221,6 +222,7 @@
 loop optimizer         Daniel Berlin           dberlin@dberlin.org
 middle-end             Richard Guenther        rguenther@suse.de
 libcpp                 Tom Tromey              tromey@redhat.com
+blanket write          Diego Novillo           dnovillo@google.com

 Note that individuals who maintain parts of the compiler as non-algorithmic
 maintainers need approval to check in algorithmic changes or changes

Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Sorry, my first reaction to latest SC announcements was to write
immediately.  But I took time to think more about the situation (now
seing a discussion about "Non-Autopoiesis Maintainers" I am more
convinced in my decision).  Here is my thoughts.  I apologize in advance
if somebody feel offended by what I wrote.  I really have no such
intentions.

Looking at the last SC announcement, it is probably easy to get the
impression that SC is shrunk to David Edelsohn, may be Mark Mitchell
and Gerald Pfeifer.  I see that some people already associate SC only
with David or see him as a single conductor to/from SC (David, nothing
personal.  You are very active and that is good).  But where are the
other members.  By the way this expression is contradict with the
original SC goal creation.

Could you please give us more explanation about your decisions.  Could
you please be more open in your work.  It is natural.  We all work on
open source project.  Some GCC developers don't follow all GCC
development and it would be nice to have an explanation even for
trivial cases of appointments.

For example, about latest appointments of Diego and Ian as GWP.  They
are good guys but I don't see Diego actively working on RTL or Ian
actively working on tree-SSA.  I understand we need more maintainers
and I know others actively working guys (e.g. Paolo Bonzini on rtl or
Jan on upper level).  May be you approached them and they rejected to
be maintainers.  We don't know because there is no explanation.
Without this it looks like a political decision.

Google became active in gcc development and I am sure they will be
more active looking at how they are hunting for good GCC developers
for now.  Nothing wrong to appoint someone from Google to SC to have a
better balance of power.  That was major motivation of SC creation.

If somebody from SC does not follow gcc development and community for
a long time, could you please be more active or think about the
leaving position.  Nothing is wrong with that.  Almost ten years have
been gone since SC creation.  Many things have been changed.

Sorry, I hope this critics (and I know that is not only mine opinion)
is in interests of SC and GCC community.

Vlad

Re: Some thoughts about steerring commitee work

[Richard Kenner]

> Looking at the last SC announcement, it is probably easy to get the
> impression that SC is shrunk to David Edelsohn, may be Mark Mitchell
> and Gerald Pfeifer.  

Those three people are indeed the ones that usually *speak for* the SC,
but you have absolutely no way of knowing how many of the members of the
SC are actually involved in a discussion of any topic.

> Could you please give us more explanation about your decisions.  Could
> you please be more open in your work.  It is natural.  

No, it isn't.  Decisions over maintainership isn't technical, but are
instead discussions about *people*.  When you say "I'm going to let this
person do XYZ", you're often implicitly saying that you're not going to
let some other person do it.  These kinds of decisions are often very tricky
and don't, to me, seem like the sorts of things you want discussed in
public forums.

> Without this it looks like a political decision.

Maintainership decisions are, almost by definition, "political", because
they relate to policies and project structure.

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Richard Kenner wrote:

>>Looking at the last SC announcement, it is probably easy to get the
>>impression that SC is shrunk to David Edelsohn, may be Mark Mitchell
>>and Gerald Pfeifer.  
>>    
>>
>
>Those three people are indeed the ones that usually *speak for* the SC,
>but you have absolutely no way of knowing how many of the members of the
>SC are actually involved in a discussion of any topic.
>
>  
>
Richard, thanks for the answers. That is already an explanation.  Even 
saying this is to be open.

That is very good to know especially from you who was a GCC project 
manager sometime ago.

I think only SC members know their situation well.  But I wrote about my 
impression which I got on IRC and latest SC announcements.  I think I am 
not alone.  E.g. look at the last paragraph.

Ken Zadeck wrote:

Spelling errors, changelog fixes and MAINTAINERS.  Nothing of real
interest except that there is now a new category of maintainer: the
"Non-Autopoiesis Maintainers".

I realize that this will send everyone to the dictionary/wikipedia so
here is the entry:
http://en.wikipedia.org/wiki/Autopoiesis

Note that this was approved by Edelsohn, but I assume that he might be
open to a different name even though non-autopoiesis is technically
correct.  These are maintainers who cannot review their own patches. 


>>Could you please give us more explanation about your decisions.  Could
>>you please be more open in your work.  It is natural.  
>>    
>>
>
>No, it isn't.  Decisions over maintainership isn't technical, but are
>instead discussions about *people*.  When you say "I'm going to let this
>person do XYZ", you're often implicitly saying that you're not going to
>let some other person do it.  These kinds of decisions are often very tricky
>and don't, to me, seem like the sorts of things you want discussed in
>public forums.
>
>  
>
I am agree with you.  But more information would be helpful.  Like these 
people are actively working on this part of project (and going to 
actively working on this part of project) and therefore they are 
promoted to ...

Even if it is not good with your point of view.  It would be nice to 
write somewhere about the SC policy.  That is what I call to be more open.

>>Without this it looks like a political decision.
>>    
>>
>
>Maintainership decisions are, almost by definition, "political", because
>they relate to policies and project structure.
>  
>
I meant a bad politics (like company power balance or personal favors).

I hope not all my thoughts are wrong.  And the discussion will be helpful.

RE: Some thoughts about steering committee work

[Kenneth Zadeck]

> Sorry, my first reaction to latest SC announcements was to write
> immediately.  But I took time to think more about the situation (now
> seing a discussion about "Non-Autopoiesis Maintainers" I am more
> convinced in my decision).  Here is my thoughts.  I apologize in advance
> if somebody feel offended by what I wrote.  I really have no such
> intentions.
> 
> Looking at the last SC announcement, it is probably easy to get the
> impression that SC is shrunk to David Edelsohn, may be Mark Mitchell
> and Gerald Pfeifer.  I see that some people already associate SC only
> with David or see him as a single conductor to/from SC (David, nothing
> personal.  You are very active and that is good).  But where are the
> other members.  By the way this expression is contradict with the
> original SC goal creation.

Let me set the record straight about "Non-Autopoiesis Maintainers".

The steering committee made Paolo Bonzini, Seongbae Park and myself
maintainers of the rtl level dataflow analysis.  That was their
decision.  Among the three of us, we decided for our own reasons, that
it was appropriate that we follow the same rule as the Fortran people:
not approving in our own patches.  Since this is just a subset of
the actual privileges that we have been granted, I so no reason to ask
for approval of the steering committee.

Paolo raised the point that we should somehow make this apparent in
MAINTAINERS.  After doing some web searching I found the term
Autopoiesis and it seemed appropriate and since David Edelsohn did not
object, I edited the file.  (Since that time Willy has pointed out
that the term "Allopoietic Maintainers" would be more correct and so
it probably should be changed.  I took Latin in high school, not
Greek.)

I think that it may be true that some larger group of people may wish
to comment on the name of this category of maintainer, especially if
someone really does have a good name.  However, putting a name in the
file is just not that big a deal.  It is easily changed.

Kenny

Re: Some thoughts about steerring commitee work

[Joe Buck]

On Fri, Jun 15, 2007 at 08:50:49AM -0400, Vladimir N. Makarov wrote:
> Looking at the last SC announcement, it is probably easy to get the
> impression that SC is shrunk to David Edelsohn, may be Mark Mitchell
> and Gerald Pfeifer.

That would be a mistake.  Different SC members play different roles.  Many
members play a role similar to outside members of boards of directors, and
the intent is to represent users, not just developers.  For example, David
Miller represents the interests of the Linux kernel, Joel Sherill
represents embedded systems, Toon represents Fortran, etc.  David Edelsohn
has been handling most of the announcements of decisions lately, but he is
not personally appointing people; he's announcing the results of a vote.

> Could you please give us more explanation about your decisions.  Could
> you please be more open in your work.

The SC actually does very little.  Almost all of the work is conducted
via this list, IRC, etc.  The day-to-day decisions are made by
maintainers.  Often two weeks go by without a message on the SC list.

> Some GCC developers don't follow all GCC
> development and it would be nice to have an explanation even for
> trivial cases of appointments.

If you feel that someone should be appointed to some role, you can
contact an SC member and it can be discussed.

> For example, about latest appointments of Diego and Ian as GWP.  They
> are good guys but I don't see Diego actively working on RTL or Ian
> actively working on tree-SSA.

They were not granted unlimited GWP, but rather a limited form that
we call "non-algorithmic".  See

http://gcc.gnu.org/ml/gcc/2006-11/msg00582.html

for an explanation of what this means.  Ian can't mess with the guts
of tree-SSA without approval from a maintainer in that area, for example.
These kinds of things represent a judgment call.  In many cases the key
factor is whether the person knows what he does not know, and when he
needs to ask others for help.

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Joe Buck wrote:

>On Fri, Jun 15, 2007 at 08:50:49AM -0400, Vladimir N. Makarov wrote:
>  
>
>>Looking at the last SC announcement, it is probably easy to get the
>>impression that SC is shrunk to David Edelsohn, may be Mark Mitchell
>>and Gerald Pfeifer.
>>    
>>
>
>That would be a mistake.  Different SC members play different roles.  Many
>members play a role similar to outside members of boards of directors, and
>the intent is to represent users, not just developers.  For example, David
>Miller represents the interests of the Linux kernel, Joel Sherill
>represents embedded systems, Toon represents Fortran, etc.  David Edelsohn
>has been handling most of the announcements of decisions lately, but he is
>not personally appointing people; he's announcing the results of a vote.
>
>  
>
>
Thanks, for the clarification, Joe.  I always like to put users first.  
But I've just been thinking how some SC members which are not involed 
development make right decision during a vote about the appointments.

>>Some GCC developers don't follow all GCC
>>development and it would be nice to have an explanation even for
>>trivial cases of appointments.
>>    
>>
>
>If you feel that someone should be appointed to some role, you can
>contact an SC member and it can be discussed.
>
>  
>
Sorry, it is even make me a bit scary becuase I don't know when the SC 
decides that we need more maintainers and what maintainers.  When should 
we propose.  After that I am just starting to think who usually propose 
them.

In this situation, in my humble opinion it is better to inform 
developers about doing such decision and ask them candidates.

I am agree with Richard that is a tricky political question.  In this 
case people could send candidates anonymously.

>>For example, about latest appointments of Diego and Ian as GWP.  They
>>are good guys but I don't see Diego actively working on RTL or Ian
>>actively working on tree-SSA.
>>    
>>
>
>They were not granted unlimited GWP, but rather a limited form that
>we call "non-algorithmic".  See
>
>http://gcc.gnu.org/ml/gcc/2006-11/msg00582.html
>
>for an explanation of what this means.  Ian can't mess with the guts
>of tree-SSA without approval from a maintainer in that area, for example.
>These kinds of things represent a judgment call.  In many cases the key
>factor is whether the person knows what he does not know, and when he
>needs to ask others for help.
>
>
>  
>
Please don't get me wrong, I am not against Ian or Diego.  I think a lot 
of people could do non-algorithmic GWP (altough another question do they 
want to).  I've just thinking about improving the decision making.

I am sorry, I feel like I am annoying, please just tell me about that 
and I will stop.

Vlad

Re: Some thoughts about steerring commitee work

[Joe Buck]

On Fri, Jun 15, 2007 at 01:49:13PM -0400, Vladimir N. Makarov wrote:
> Thanks, for the clarification, Joe.  I always like to put users first.  
> But I've just been thinking how some SC members which are not involed 
> development make right decision during a vote about the appointments.

Generally by deferring to those who know, or if there's a disagreement,
by asking others who know.

Re: Some thoughts about steerring commitee work

[Ian Lance Taylor]

"Vladimir N. Makarov" <vmakarov@redhat.com> writes:

> For example, about latest appointments of Diego and Ian as GWP.  They
> are good guys but I don't see Diego actively working on RTL or Ian
> actively working on tree-SSA.

Just for the record, I was already a full middle-end maintainer before
the recent announcement, and (I assume) I retain that status.  That
is, I am permitted to make any reasonable change to the tree-ssa code,
including an algorithmic change.  My most recent patch was to the
aliasing code, in the tree-ssa passes.  That said, obviously I'm only
going to make changes that I understand.

I've been lobbying for some time, on IRC, for more people to be able
to fill in the holes in the maintainership patterns.  Most of the
existing global maintainers are inactive.  There are areas of the code
which are not covered by the other maintainership groupings.  Thus
there are areas where patches go unreviewed.  I believe, though I have
not been told, that non-algorithmic global maintainer is intended to
address this gap.  Making me one of the people with that role is most
likely following the principle that the person who complains gets the
job.

I have no reason to believe that these appointments have anything to
do with our employer.  (On the other hand, I suppose I have no reason
to believe that they don't.)  I've been hacking gcc longer than most
people, at five different companies, and I was a middle-end maintainer
before I joined Google.  Diego, while a comparative newcomer, has
obviously been a significant force in gcc for several years.

Ian

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Ian Lance Taylor wrote:

>I've been lobbying for some time, on IRC, for more people to be able
>to fill in the holes in the maintainership patterns.  Most of the
>existing global maintainers are inactive.  There are areas of the code
>which are not covered by the other maintainership groupings.  Thus
>there are areas where patches go unreviewed.  I believe, though I have
>not been told, that non-algorithmic global maintainer is intended to
>address this gap.  Making me one of the people with that role is most
>likely following the principle that the person who complains gets the
>job.
>
>  
>
Ian, may be I am wrong but I see a problem that some important for all 
GCC community things are discussed only on IRC.  Not all people are on 
IRC.  Moreover some people avoiding the IRC for some reasons.

Re: Some thoughts about steerring commitee work

[Ian Lance Taylor]

"Vladimir N. Makarov" <vmakarov@redhat.com> writes:

> Ian Lance Taylor wrote:
> 
> >I've been lobbying for some time, on IRC, for more people to be able
> >to fill in the holes in the maintainership patterns.  Most of the
> >existing global maintainers are inactive.  There are areas of the code
> >which are not covered by the other maintainership groupings.  Thus
> >there are areas where patches go unreviewed.  I believe, though I have
> >not been told, that non-algorithmic global maintainer is intended to
> >address this gap.  Making me one of the people with that role is most
> >likely following the principle that the person who complains gets the
> >job.
> >
> >
> Ian, may be I am wrong but I see a problem that some important for all
> GCC community things are discussed only on IRC.  Not all people are on
> IRC.  Moreover some people avoiding the IRC for some reasons.

There will always be private conversations about GCC.  You can't
prevent that.  IRC is less private than other places.

When I said lobbying, I meant only that I complained about it.  I
could have complained about it in e-mail the same way.  There were no
important conversations about it on IRC.  If the SC members use IRC at
all, they don't use #gcc.

I'm having a hard time interpreting your comments because I don't
understand what you want to be done differently.

Speaking only for myself, I think it would be silly to stop using IRC.
I don't think it would work for the SC to conduct their deliberations
in public.  I do think that the SC membership should change from time
to time, but I have no concrete proposal for how to make that happen.
I do think that there should be more active global maintainers, but
the SC appears to disagree.  I do think that the gcc is extremely
successful as free software projects go, which is not to say that it
can not be improved.

Ian

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Ian Lance Taylor wrote:

>"Vladimir N. Makarov" <vmakarov@redhat.com> writes:
>
>  
>
>>Ian Lance Taylor wrote:
>>
>>    
>>
>>>I've been lobbying for some time, on IRC, for more people to be able
>>>to fill in the holes in the maintainership patterns.  Most of the
>>>existing global maintainers are inactive.  There are areas of the code
>>>which are not covered by the other maintainership groupings.  Thus
>>>there are areas where patches go unreviewed.  I believe, though I have
>>>not been told, that non-algorithmic global maintainer is intended to
>>>address this gap.  Making me one of the people with that role is most
>>>likely following the principle that the person who complains gets the
>>>job.
>>>
>>>
>>>      
>>>
>>Ian, may be I am wrong but I see a problem that some important for all
>>GCC community things are discussed only on IRC.  Not all people are on
>>IRC.  Moreover some people avoiding the IRC for some reasons.
>>    
>>
>
>There will always be private conversations about GCC.  You can't
>prevent that.  IRC is less private than other places.
>
>When I said lobbying, I meant only that I complained about it.  I
>could have complained about it in e-mail the same way.  There were no
>important conversations about it on IRC.  If the SC members use IRC at
>all, they don't use #gcc.
>  
>
>I'm having a hard time interpreting your comments because I don't
>understand what you want to be done differently.
>
>  
>
I am not against IRC.  We have free speech right (which means some 
responsibility too).  We could (and we do) discuss whatever we want 
wherever we want with whom we want.  I just wish that some discussion 
important for all community were discussed not only IRC because they 
involve not only people who are on IRC.

>Speaking only for myself, I think it would be silly to stop using IRC.
>I don't think it would work for the SC to conduct their deliberations
>in public.
>
I don't like to see the deliberation in public too (it would be a 
nightmare for developers ego).  But I'd like to see a bit more 
motivation and explanation in the SC decisions.  Then you would not have 
to write the first your message in this thread.

>  I do think that the SC membership should change from time
>to time, but I have no concrete proposal for how to make that happen.
>I do think that there should be more active global maintainers, but
>the SC appears to disagree.  I do think that the gcc is extremely
>successful as free software projects go, which is not to say that it
>can not be improved.
>  
>
I am agree that GCC is successful especially as a community project.  
But with my point of view, we could do better to serve our users (and 
customers)

Please, just look at those charts

https://vmakarov.108.redhat.com/nonav/spec/comparison.html

The compilation speed decrease without a performance improving (at least 
for the default case) is really scary.  I'd like to see sticking to the 
decision that every next release should be better.  Although I don't 
have ideas for now how to achieve this.

And of course, I just speak for myself too.

Re: Some thoughts about steerring commitee work

[Eric Botcazou]

> Please, just look at those charts
>
> https://vmakarov.108.redhat.com/nonav/spec/comparison.html
>
> The compilation speed decrease without a performance improving (at least
> for the default case) is really scary.

Right, I also found those charts a bit depressing, given the time and energy 
that have been put in the compiler since GCC 3.2.3.  For example, it seems 
that the Tree-SSA infrastructure has brought very little benefit in terms of 
performance in the generic case, in exchange for a massive dump of new code.

Does anyone have the beginning of an idea as to why this is so?  Did GCC hit a 
fundamental wall some time ago, for example because of its portability?

On the other hand, those efforts have not been lost, since the compiler is now 
much more modern in terms of infrastructure and algorithms.  However, before 
triggering the next internal earthquake (namely LTO), we should probably try 
to understand what's going on (or not going on).

-- 
Eric Botcazou

Re: Some thoughts about steerring commitee work

[Daniel Berlin]

On 6/15/07, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> > Please, just look at those charts
> >
> > https://vmakarov.108.redhat.com/nonav/spec/comparison.html
> >
> > The compilation speed decrease without a performance improving (at least
> > for the default case) is really scary.
>
> Right, I also found those charts a bit depressing, given the time and energy
> that have been put in the compiler since GCC 3.2.3.  For example, it seems
> that the Tree-SSA infrastructure has brought very little benefit in terms of
> performance in the generic case, in exchange for a massive dump of new code.
>
> Does anyone have the beginning of an idea as to why this is so?
> Did GCC hit a
> fundamental wall some time ago, for example because of its portability?
>
No, GCC hit a fundamental wall because its backend was not modern.
The code we generate out of tree-ssa is in general, as good or better
than other compilers generate out of their middle ends.

The problem remaining is that they have much better backends then us.

Until dataflow, *nobody* had done any sort of major undertaking to
make the *entire* backend actually modern in any way, shape or form.

> On the other hand, those efforts have not been lost, since the compiler is now
> much more modern in terms of infrastructure and algorithms.  However, before
> triggering the next internal earthquake (namely LTO), we should probably try
> to understand what's going on (or not going on).

This is not really rocket science, to be honest.
No matter how good of code you generate out of your middle end
(including LTO->middle end), if your backend does a crappy job of code
generation, you will end up with crappy code.

Our backends have done roughly the same good/bad job of generating
code since, well, forever.  Until that changes, you will see that the
only performance improvements you get in the general case are things
that the backend was too dumb to get in the first place (IE loads,
stores)

--Dan

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Eric Botcazou wrote:

>>Please, just look at those charts
>>
>>https://vmakarov.108.redhat.com/nonav/spec/comparison.html
>>
>>The compilation speed decrease without a performance improving (at least
>>for the default case) is really scary.
>>    
>>
>
>Right, I also found those charts a bit depressing, given the time and energy 
>that have been put in the compiler since GCC 3.2.3.  For example, it seems 
>that the Tree-SSA infrastructure has brought very little benefit in terms of 
>performance in the generic case, in exchange for a massive dump of new code.
>  
>
Yes, the compilation speed and SPECINT scores looks a bit depressive.  
But gcc has now more optimizations and there is more possibility to 
generate a better code for a program. Also the code size became smaller 
too.  More people use C++ than C now.  There is really improvement for 
C++ code (SPECINT contains only 1 C++ benchmark of 12 ones).

Fortunately gcc 4.3 will have also faster compilation speed than 4.2 
even with the df infrastructure (which may be, and I hope, helps to 
improve the code finally).  That is because some work was done to speed 
up tree-SSA infrastructure (and Paolo Bonizini's frwprop) to improve the 
compilation speed.

I think LTO will speed up the generated code too although with, I think, 
some signficant compilation slowdown.  And it might be not usefull for 
big programs (e.g. i remember my experience when I forced ICC to compile 
a program for half hour when with less agressive optimizations it would 
compile for a few minutes).

Re: Some thoughts about steerring commitee work

[Eric Botcazou]

> No, GCC hit a fundamental wall because its backend was not modern.
> The code we generate out of tree-ssa is in general, as good or better
> than other compilers generate out of their middle ends.
>
> The problem remaining is that they have much better backends then us.
>
> Until dataflow, *nobody* had done any sort of major undertaking to
> make the *entire* backend actually modern in any way, shape or form.

I presume that "backend" means the RTL part of the compiler, right?  So we 
should focus our efforts on the low-level part of the compiler, rather than 
on the high-level part?  E.g the register allocator?

> Our backends have done roughly the same good/bad job of generating
> code since, well, forever.  Until that changes, you will see that the
> only performance improvements you get in the general case are things
> that the backend was too dumb to get in the first place (IE loads,
> stores)

Note that Tree-SSA was supposed to butcher the RTL optimizers and replace them 
with something less "crappy" though.

-- 
Eric Botcazou

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Eric Botcazou wrote:

>>No, GCC hit a fundamental wall because its backend was not modern.
>>The code we generate out of tree-ssa is in general, as good or better
>>than other compilers generate out of their middle ends.
>>
>>The problem remaining is that they have much better backends then us.
>>
>>Until dataflow, *nobody* had done any sort of major undertaking to
>>make the *entire* backend actually modern in any way, shape or form.
>>    
>>
>
>I presume that "backend" means the RTL part of the compiler, right?  So we 
>should focus our efforts on the low-level part of the compiler, rather than 
>on the high-level part?  E.g the register allocator?
>
>  
>
I think a good register allocator and putting more on pseudo-registers 
(better escape analysis) could help x86/x86_64.

As for C++, I think we need more OO language specific optimizations.  I 
don't know what the status of devirtualizion which was reported on the 
previous summit.

Re: Some thoughts about steerring commitee work

[Richard Kenner]

    Our backends have done roughly the same good/bad job of generating
    code since, well, forever.  Until that changes, you will see that the
    only performance improvements you get in the general case are things
    that the backend was too dumb to get in the first place (IE loads,
    stores)

I don't think that's fair.  There are many things that can be done at
higher level that could never be done in a backend, such as the very fancy
tail recursion we do and some loop optimizations.  One can construct quite
amazing test cases for them.  What's disappointing to me is that it seems
they don't trigger nearly as much in real code as one would like to see.

Re: Some thoughts about steerring commitee work

[Tobias Burnus]

Vladimir N. Makarov wrote:
> Eric Botcazou wrote:
>>> Please, just look at those charts
>>>
>>> https://vmakarov.108.redhat.com/nonav/spec/comparison.html
>>>
>>> The compilation speed decrease without a performance improving (at least
>>> for the default case) is really scary.
>>>   
>>
>> Right, I also found those charts a bit depressing, given the time and
>> energy that have been put in the compiler since GCC 3.2.3.


To cheer you up, you can look at the number for gfortran with the
Polyhedron benchmark:

http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/#rt

gfortran 4.1.3 is up to 119% slower than gfortran 4.3, whereas the speed
regressions are maximally 12%.
For the geometric mean, gfortran 4.2 needs 12% longer than 4.3

(All values for AMD64.)

Looking at the geometric mean of the 16 tests, 4.3. is only 5% slower
than Intel's ifort 9.1, 6% than ifort 10.0 and sunf95, and 16% slower
than Pathscale.*

I think this is not bad at all!

Tobias

PS: The df merge has caused speed regression (geometric mean) of around 1%.

*One can probably better tune the parameter of all the compilers.

Re: Some thoughts about steerring commitee work

[Ian Lance Taylor]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:

> > Please, just look at those charts
> >
> > https://vmakarov.108.redhat.com/nonav/spec/comparison.html
> >
> > The compilation speed decrease without a performance improving (at least
> > for the default case) is really scary.
> 
> Right, I also found those charts a bit depressing, given the time and energy 
> that have been put in the compiler since GCC 3.2.3.  For example, it seems 
> that the Tree-SSA infrastructure has brought very little benefit in terms of 
> performance in the generic case, in exchange for a massive dump of new code.
> 
> Does anyone have the beginning of an idea as to why this is so?  Did GCC hit a 
> fundamental wall some time ago, for example because of its portability?
> 
> On the other hand, those efforts have not been lost, since the compiler is now 
> much more modern in terms of infrastructure and algorithms.  However, before 
> triggering the next internal earthquake (namely LTO), we should probably try 
> to understand what's going on (or not going on).

These charts are certainly discouraging.  On the other hand, for some
real code we're seeing each new version of gcc produce an incremental
runtime improvement.  So I'm not sure what to make of it.

This is hardly a new thought, but I believe that for the i386 gcc is
handicapped by reload.  No matter how smart we are before reload, it
just take one poor decision by reload in an inner loop and we've lost
all the gains.  Reload has enormous complexities which are mostly
irrelevant for the i386.  And I think that the idea of doing register
allocation separately from spill code generation does not make sense
on the i386.

I don't think gcc has hit any sort of wall, except insofar as we have
no plan for eliminating reload.  I don't think portability comes into
play here.

That said, I certainly agree that we should try to figure out what is
going on as much as possible.

I also want to say that at present LTO is a collection of different
projects.  Most of them are aimed directly at speeding up the
compiler, reducing compile time.  So far nobody is working on any
changes to the actual optimization framework.  So I'm not too
concerned yet about LTO in this context.  I certainly agree that when
LTO moves into an optimization phase, we need to make sure that any
default passes pay off in terms of compilation time or runtime
performance.

Ian

Re: Some thoughts about steerring commitee work

[Ian Lance Taylor]

"Vladimir N. Makarov" <vmakarov@redhat.com> writes:

> >>>I've been lobbying for some time, on IRC, for more people to be able
> >>>to fill in the holes in the maintainership patterns.  Most of the
> >>>existing global maintainers are inactive.  There are areas of the code
> >>>which are not covered by the other maintainership groupings.  Thus
> >>>there are areas where patches go unreviewed.  I believe, though I have
> >>>not been told, that non-algorithmic global maintainer is intended to
> >>>address this gap.  Making me one of the people with that role is most
> >>>likely following the principle that the person who complains gets the
> >>>job.
> >>>
> >>>
> >>>
> >>Ian, may be I am wrong but I see a problem that some important for all
> >>GCC community things are discussed only on IRC.  Not all people are on
> >>IRC.  Moreover some people avoiding the IRC for some reasons.
> >>
> >
> >There will always be private conversations about GCC.  You can't
> >prevent that.  IRC is less private than other places.
> >
> >When I said lobbying, I meant only that I complained about it.  I
> >could have complained about it in e-mail the same way.  There were no
> >important conversations about it on IRC.  If the SC members use IRC at
> >all, they don't use #gcc.
> >  I'm having a hard time interpreting your comments because I don't
> >understand what you want to be done differently.
> >
> >
> I am not against IRC.  We have free speech right (which means some
> responsibility too).  We could (and we do) discuss whatever we want
> wherever we want with whom we want.  I just wish that some discussion
> important for all community were discussed not only IRC because they
> involve not only people who are on IRC.

I'm still honestly trying to figure out just what you mean here.

Do you mean: the discussion that there are holes in maintainership
patterns is important for the community, and should have been
discussed on the mailing list, rather than IRC?  To me that doesn't
rise to the level of being important for the community.  I mean, I
toss off all sorts of comments all the time.  In my last message I
tossed off a comment about reload being our major problem on the i386.
I hope and assume that most people ignore most of these comments.  It
wouldn't make sense for me or anyone to send out an e-mail note for
every random thought.

Or do you mean something eles?

The important thing for the community is that Diego and I have now
been appointed non-algorithmic global maintainers.  That was duly
announced.  I guess we could have had a discussion about whether Diego
and I should have been appointed, or whether that position should have
been created at all.  That discussion does have some importance for
the community, but it didn't happen on IRC, at least not when I was
there.  If it happened at all, it happened on the steering committee
mailing list.  So, is that what you mean?  Or am I just totally
offbase?

If I'm getting carried away with this topic, let me know.

Ian

Re: Some thoughts about steerring commitee work

[H. J. Lu]

On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:
> 
> This is hardly a new thought, but I believe that for the i386 gcc is
> handicapped by reload.  No matter how smart we are before reload, it
> just take one poor decision by reload in an inner loop and we've lost
> all the gains.  Reload has enormous complexities which are mostly
> irrelevant for the i386.  And I think that the idea of doing register
> allocation separately from spill code generation does not make sense
> on the i386.
> 

Why don't we turn on vectorizer at -O3 or even -O2, depending on
ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
-ftree-vectorizer-verbose=1, there are 82 loops vectorized in
gcc source. There are no regressions. There are not much changes
in bootstrap time as well as "make check" time.


H.J.

Re: Some thoughts about steerring commitee work

[Andrew Pinski]

On 6/15/07, H. J. Lu <hjl@lucon.org> wrote:
>
> Why don't we turn on vectorizer at -O3 or even -O2, depending on
> ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> gcc source. There are no regressions. There are not much changes
> in bootstrap time as well as "make check" time.

Guess you did not see my PR 32093 then where -ftree-vectorize breaks
some testcase?

Thanks,
Andrew Pinski

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Ian Lance Taylor wrote:

>
>These charts are certainly discouraging.  On the other hand, for some
>real code we're seeing each new version of gcc produce an incremental
>runtime improvement.  So I'm not sure what to make of it.
>
>This is hardly a new thought, but I believe that for the i386 gcc is
>handicapped by reload.  No matter how smart we are before reload, it
>just take one poor decision by reload in an inner loop and we've lost
>all the gains.  Reload has enormous complexities which are mostly
>irrelevant for the i386.  And I think that the idea of doing register
>allocation separately from spill code generation does not make sense
>on the i386.
>
>  
>
I would agree if we were talking about all gcc register allocation.  All 
gcc register allocation is really bad.  But there are different spills.  
Ones are because of the register pressure and another ones are because 
of the insn operand constraint combination.  The both can be taken into 
account before the reload in some acceptable way.

That is what impression I got from implementation of a register 
allocation without the reload for x86 and x86_64 and one with  the 
reload.  You can get the same improvement for x86.

As for x86_64 I found that spilling because register pressure is not so 
high right now (at least for x86_64 and for SPEC2000 because it has 
exactly in 2.5 more times more integer registers).  Therefore I 
mentioned about putting more values on the registers.  I hope LTO will 
help in that way too.
 
Reload is a mess but in local context it is doing a good job.  It was 
refined for many years and conceptually it is not so difficult to 
understand.  Removing it is not a rewarding job probably.  May be we 
need just to improve it and have a better documentation.

>I don't think gcc has hit any sort of wall, except insofar as we have
>no plan for eliminating reload.  I don't think portability comes into
>play here.
>
>That said, I certainly agree that we should try to figure out what is
>going on as much as possible.
>
>I also want to say that at present LTO is a collection of different
>projects.  Most of them are aimed directly at speeding up the
>compiler, reducing compile time.  So far nobody is working on any
>changes to the actual optimization framework.  So I'm not too
>concerned yet about LTO in this context.  I certainly agree that when
>LTO moves into an optimization phase, we need to make sure that any
>default passes pay off in terms of compilation time or runtime
>performance. 
>
>  
>
I am agree that LTO is the next big project which could help gcc in many 
way.  And we need to do this to keep gcc in pace with other compilers 
(mostly Intel).

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Ian Lance Taylor wrote:

>
>>>>Ian, may be I am wrong but I see a problem that some important for all
>>>>GCC community things are discussed only on IRC.  Not all people are on
>>>>IRC.  Moreover some people avoiding the IRC for some reasons.
>>>>
>>>>        
>>>>
>>>There will always be private conversations about GCC.  You can't
>>>prevent that.  IRC is less private than other places.
>>>
>>>When I said lobbying, I meant only that I complained about it.  I
>>>could have complained about it in e-mail the same way.  There were no
>>>important conversations about it on IRC.  If the SC members use IRC at
>>>all, they don't use #gcc.
>>> I'm having a hard time interpreting your comments because I don't
>>>understand what you want to be done differently.
>>>
>>>
>>>      
>>>
>>I am not against IRC.  We have free speech right (which means some
>>responsibility too).  We could (and we do) discuss whatever we want
>>wherever we want with whom we want.  I just wish that some discussion
>>important for all community were discussed not only IRC because they
>>involve not only people who are on IRC.
>>    
>>
>
>I'm still honestly trying to figure out just what you mean here.
>
>Do you mean: the discussion that there are holes in maintainership
>patterns is important for the community, and should have been
>discussed on the mailing list, rather than IRC?  To me that doesn't
>rise to the level of being important for the community.  I mean, I
>toss off all sorts of comments all the time.  In my last message I
>tossed off a comment about reload being our major problem on the i386.
>I hope and assume that most people ignore most of these comments.  It
>wouldn't make sense for me or anyone to send out an e-mail note for
>every random thought.
>
>Or do you mean something eles?
>
>The important thing for the community is that Diego and I have now
>been appointed non-algorithmic global maintainers.  That was duly
>announced.  I guess we could have had a discussion about whether Diego
>and I should have been appointed, or whether that position should have
>been created at all.  That discussion does have some importance for
>the community, but it didn't happen on IRC, at least not when I was
>there.  If it happened at all, it happened on the steering committee
>mailing list.  So, is that what you mean?  Or am I just totally
>offbase?
>
>If I'm getting carried away with this topic, let me know.
>
>  
>
Ian, no you are perfectly right about the topic.  To be honest I meant 
the both.

The first I agree with you that we need more global maintainers because 
some of them (I mean Richard) is not active most of time.  There are 
always patches where the reviewer need to have a good knowledge of all 
compiler.  I've just rewieved the patch where necessary to know 
scheduler, software pipelining, ia64 and ppc machine-dependent code.  So 
four people needs to approve the patch.  And I think that we needed to 
discuss lack of global maintainers on more wider basis (not just on IRC).

The second, it was a bit suspicious to me that in one day two Google 
guys got global maintainership although as I wrote Diego did not work on 
rtl for a long time.  One the other hand, I see Google has a good 
developers and may be I was a bit paranoid.  But after this discussion I 
see the situation more clear and not soo gloomy.  With my point of view, 
maintainerhsip is a burden, it distracts people from an interesting 
job.  I should be glad that there are some people who is going to take it.

Ian, I am sorry,  I'll be on vacation next week and will be 
inaccessible.  So if you want to discuss something more, we could do 
that in a week. In any case, we have such opportunity soon on the gcc 
summit.   But this discussion already really helped me to understand the 
situation better.

Vlad

Re: Some thoughts about steerring commitee work

[Vladimir N. Makarov]

H. J. Lu wrote:

>On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:
>  
>
>>This is hardly a new thought, but I believe that for the i386 gcc is
>>handicapped by reload.  No matter how smart we are before reload, it
>>just take one poor decision by reload in an inner loop and we've lost
>>all the gains.  Reload has enormous complexities which are mostly
>>irrelevant for the i386.  And I think that the idea of doing register
>>allocation separately from spill code generation does not make sense
>>on the i386.
>>
>>    
>>
>
>Why don't we turn on vectorizer at -O3 or even -O2, depending on
>ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
>-ftree-vectorizer-verbose=1, there are 82 loops vectorized in
>gcc source. There are no regressions. There are not much changes
>in bootstrap time as well as "make check" time.
>
>  
>
A mount ago I did some measurements of the effect of the vectorizer for 
Core2 in 64-bit mode.  Unfortunately, I saw small improvement (as I 
remember less than 1% for SPECInt2000).

Vectorizer is a big a project and may be we will see more improvements 
in future. They promissed implement SLP two years ago and now I see it 
happens.  It would be nice  to see it not only in loops.
 
Vlad

Re: Some thoughts about steerring commitee work

[Richard Kenner]

> Reload is a mess but in local context it is doing a good job. 

That's exactly the point: it makes sense and does the right thing when
viewed locally,  but there's little feedback and/or linkage between reload
and the other optimizers regarding global decisions.  So those global
decisions are often made without being too conscious of such things as
register pressure and reload has to make decisions without being that aware
of what it might be undoing that was previously done.  Improving this is
a very hard problem that many people have worked on for years without
much success.  One could even argue that moving optimizations to higher
level constructions (e.g., from RTL to tree) worsens the problem because
you have even less low-level knowlege then.

Re: Some thoughts about steerring commitee work

[Richard Kenner]

> The second, it was a bit suspicious to me that in one day two Google 
> guys got global maintainership although as I wrote Diego did not work on 
> rtl for a long time.  One the other hand, I see Google has a good 
> developers and may be I was a bit paranoid.  

Right.  A few years ago, if two developers got global maintainership, it's
likely they'd both be from RedHat.  This just reflects the movement of
people between companies, in my opinion.

Re: Some thoughts about steerring commitee work

[H. J. Lu]

On Fri, Jun 15, 2007 at 07:17:22PM -0700, Andrew Pinski wrote:
> On 6/15/07, H. J. Lu <hjl@lucon.org> wrote:
> >
> >Why don't we turn on vectorizer at -O3 or even -O2, depending on
> >ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> >-ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> >gcc source. There are no regressions. There are not much changes
> >in bootstrap time as well as "make check" time.
> 
> Guess you did not see my PR 32093 then where -ftree-vectorize breaks
> some testcase?

I can't reproduce it with Intel BID library.


H.J.

Re: Some thoughts about steerring commitee work

[H. J. Lu]

On Fri, Jun 15, 2007 at 11:33:52PM -0400, Vladimir N. Makarov wrote:
> H. J. Lu wrote:
> 
> >On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:
> > 
> >
> >>This is hardly a new thought, but I believe that for the i386 gcc is
> >>handicapped by reload.  No matter how smart we are before reload, it
> >>just take one poor decision by reload in an inner loop and we've lost
> >>all the gains.  Reload has enormous complexities which are mostly
> >>irrelevant for the i386.  And I think that the idea of doing register
> >>allocation separately from spill code generation does not make sense
> >>on the i386.
> >>
> >>   
> >>
> >
> >Why don't we turn on vectorizer at -O3 or even -O2, depending on
> >ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> >-ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> >gcc source. There are no regressions. There are not much changes
> >in bootstrap time as well as "make check" time.
> >
> > 
> >
> A mount ago I did some measurements of the effect of the vectorizer for 
> Core2 in 64-bit mode.  Unfortunately, I saw small improvement (as I 
> remember less than 1% for SPECInt2000).

Vectorizer works only when there are vector instructions available
which vectorizer can take advantage of. Adding -mssse3 should make
vectorizer to work a little bit better. SSE4 will improve vectorizer
even more.

> 
> Vectorizer is a big a project and may be we will see more improvements 
> in future. They promissed implement SLP two years ago and now I see it 
> happens.  It would be nice  to see it not only in loops.

There are quite a few known simple cases which vectorizer fails to
vectorize. Also, not all x86 vector instructions are supported by
vectorizer.


H.J.

Re: Some thoughts about steerring commitee work

[Joel Sherrill]

Richard Kenner wrote:
>> The second, it was a bit suspicious to me that in one day two Google 
>> guys got global maintainership although as I wrote Diego did not work on 
>> rtl for a long time.  One the other hand, I see Google has a good 
>> developers and may be I was a bit paranoid.  
>>     
>
> Right.  A few years ago, if two developers got global maintainership, it's
> likely they'd both be from RedHat.  This just reflects the movement of
> people between companies, in my opinion.
>   
Richard is right!  And if you go back further, a majority of gcc
maintainers probably worked at Cygnus.

When considering nominations, I certainly don't consider where
they work as much as their technical capabilities and ability
to work well in the GCC community. 

Watching the email addresses of people change, I know I have
noticed the same people at Cygnus, RedHat, Apple, Google, BSDi,
and others.  But it doesn't change their technical ability and as long
as they are working on gcc in a responsible manner and not causing
strive in the community, that's what matters.

Note that on the steering committee we represent technical areas
NOT the companies we work for at any given time.

--joel

Re: Some thoughts about steerring commitee work

[Dorit Nuzman]

> On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:
> >
> > This is hardly a new thought, but I believe that for the i386 gcc is
> > handicapped by reload.  No matter how smart we are before reload, it
> > just take one poor decision by reload in an inner loop and we've lost
> > all the gains.  Reload has enormous complexities which are mostly
> > irrelevant for the i386.  And I think that the idea of doing register
> > allocation separately from spill code generation does not make sense
> > on the i386.
> >
>
> Why don't we turn on vectorizer at -O3 or even -O2, depending on
> ISA?

I think we want to make more progress on the cost model first, so that we
don't greedily vectorize unless we think it's worth while.

> I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> gcc source. There are no regressions. There are not much changes
> in bootstrap time as well as "make check" time.
>

that's good to know,

dorit

>
> H.J.

Re: Some thoughts about steerring commitee work

[Dorit Nuzman]

> H. J. Lu wrote:
>
> >On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:
> >
> >
> >>This is hardly a new thought, but I believe that for the i386 gcc is
> >>handicapped by reload.  No matter how smart we are before reload, it
> >>just take one poor decision by reload in an inner loop and we've lost
> >>all the gains.  Reload has enormous complexities which are mostly
> >>irrelevant for the i386.  And I think that the idea of doing register
> >>allocation separately from spill code generation does not make sense
> >>on the i386.
> >>
> >>
> >>
> >
> >Why don't we turn on vectorizer at -O3 or even -O2, depending on
> >ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> >-ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> >gcc source. There are no regressions. There are not much changes
> >in bootstrap time as well as "make check" time.
> >
> >
> >
> A mount ago I did some measurements of the effect of the vectorizer for
> Core2 in 64-bit mode.  Unfortunately, I saw small improvement (as I
> remember less than 1% for SPECInt2000).
>

As far as I know there aren't many opportunities for vectorization in
SPECInt2000 that have much impact on performance. The one exception is gzip
that has 2 loops that when vectorized give ~8% improvement on the entire
benchmark. We vectorized it and got this improvement with an old version of
autovect-branch that had some hacks to remove redundant casts. If I
remember correctly there's also a small hot initialization loop in eon that
gets vectorized but doesn't improve performance because of the cost of
creating the constant in a vector (unless inter-procedural constant
propagation and loop specialization takes place). I think these two cases
are pretty much it.

> Vectorizer is a big a project and may be we will see more improvements
> in future. They promissed implement SLP two years ago and now I see it
> happens.  It would be nice  to see it not only in loops.
>

Do you have specific examples where SLP helps performance out of loops?

thanks,
dorit

> Vlad
>

Re: Some thoughts about steerring commitee work

[Dorit Nuzman]

> On Fri, Jun 15, 2007 at 11:33:52PM -0400, Vladimir N. Makarov wrote:
> > H. J. Lu wrote:
> >
...
> > >
> > >
> > A mount ago I did some measurements of the effect of the vectorizer for

> > Core2 in 64-bit mode.  Unfortunately, I saw small improvement (as I
> > remember less than 1% for SPECInt2000).
>
> Vectorizer works only when there are vector instructions available
> which vectorizer can take advantage of. Adding -mssse3 should make
> vectorizer to work a little bit better. SSE4 will improve vectorizer
> even more.
>
> >
> > Vectorizer is a big a project and may be we will see more improvements
> > in future. They promissed implement SLP two years ago and now I see it
> > happens.  It would be nice  to see it not only in loops.
>
> There are quite a few known simple cases which vectorizer fails to
> vectorize.

by "known" you mean there are open missed-optimization PRs for them? (if
not - please feel free to open PRs for them!)

thanks,
dorit


> Also, not all x86 vector instructions are supported by
> vectorizer.
>
>
> H.J.

Re: Some thoughts about steerring commitee work

[Daniel Berlin]

On 6/16/07, Dorit Nuzman <DORIT@il.ibm.com> wrote:
> > H. J. Lu wrote:
> >
> > >On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:

>
> > Vectorizer is a big a project and may be we will see more improvements
> > in future. They promissed implement SLP two years ago and now I see it
> > happens.  It would be nice  to see it not only in loops.
> >
>
> Do you have specific examples where SLP helps performance out of loops?
>
hash calculations.

For md5, you can get a 2x performance improvement by straight-line
vectorizing it
sha1 is about 2-2.5x

(This assumes you do good pack/unpack placement using something like
lazy code motion)

See, for example, http://arctic.org/~dean/crypto/sha1.html

(The page is out of date, the technique they explain where they are
doing straight line computation of the hash in parallel, is exactly
what SLP would provide out of loops)

Re: Some thoughts about steerring commitee work

[Ryan Hill]

H. J. Lu wrote:

> Why don't we turn on vectorizer at -O3 or even -O2, depending on
> ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> gcc source. There are no regressions. There are not much changes
> in bootstrap time as well as "make check" time.

We have about two dozen cases of packages that break when
-ftree-vectorize is used.  I'm sure there are several more as we tend to
discourage such bug reports.

-- 
dirtyepic                 salesman said this vacuum's guaranteed
 gentoo org          it could suck an ancient virus from the sea
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

Re: Some thoughts about steerring commitee work

[H. J. Lu]

On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
> > There are quite a few known simple cases which vectorizer fails to
> > vectorize.
> 
> by "known" you mean there are open missed-optimization PRs for them? (if
> 

Yes, that is what I meant.


H.J.

Re: Some thoughts about steerring commitee work

[Tim Prince]

hjl@lucon.org wrote:
> On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
>>> There are quite a few known simple cases which vectorizer fails to
>>> vectorize.
>> by "known" you mean there are open missed-optimization PRs for them? (if
>>
> 
> Yes, that is what I meant.
> 
I'd be happy to file some PRs along this line, if there is interest.  C 
or C++, if there's more interest in that than in Fortran.  But, gfortran 
fails to vectorize more than 50% of the stuff I run into every day, 
including most everything which involves distinct sections of the same 
array or COMMON block.

Re: Some thoughts about steerring commitee work

[Dorit Nuzman]

Tim Prince <n8tm@aol.com> wrote on 17/06/2007 04:15:56:

> hjl@lucon.org wrote:
> > On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
> >>> There are quite a few known simple cases which vectorizer fails to
> >>> vectorize.
> >> by "known" you mean there are open missed-optimization PRs for them?
(if
> >>
> >
> > Yes, that is what I meant.
> >
> I'd be happy to file some PRs along this line, if there is interest.  C

yes, there is

> or C++, if there's more interest in that than in Fortran.  But, gfortran
> fails to vectorize more than 50% of the stuff I run into every day,
> including most everything which involves distinct sections of the same
> array or COMMON block.

I thought there was already a PR opened for this issue (probably by Toon),
but I can't find it :-(

thanks,
dorit

Re: Some thoughts about steerring commitee work

[Dorit Nuzman]

> H. J. Lu wrote:
>
> > Why don't we turn on vectorizer at -O3 or even -O2, depending on
> > ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> > -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> > gcc source. There are no regressions. There are not much changes
> > in bootstrap time as well as "make check" time.
>
> We have about two dozen cases of packages that break when
> -ftree-vectorize is used.  I'm sure there are several more as we tend to
> discourage such bug reports.
>

If you could take the time to find the reduced testcases and file PRs for
these, that would be most appreciated.

thanks,
dorit

> --
> dirtyepic                 salesman said this vacuum's guaranteed
>  gentoo org          it could suck an ancient virus from the sea
>   9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)
>

Re: Some thoughts about steerring commitee work

[Paolo Bonzini]

> Fortunately gcc 4.3 will have also faster compilation speed than 4.2 
> even with the df infrastructure (which may be, and I hope, helps to 
> improve the code finally).  That is because some work was done to speed 
> up tree-SSA infrastructure (and Paolo Bonizini's frwprop) to improve the 
> compilation speed.

Just something to point out: despite fwprop being often associated with 
me (in bug reports too ;-) it was the joint work of me and Steven 
Bosscher.  His name is at them top of the fwprop.c file for a reason, as 
his work, and SuSE/Novell's infrastructure, were invaluable.

Paolo

Re: Some thoughts about steerring commitee work

[Ryan Hill]

Dorit Nuzman wrote:
>> H. J. Lu wrote:
>>
>>> Why don't we turn on vectorizer at -O3 or even -O2, depending on
>>> ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
>>> -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
>>> gcc source. There are no regressions. There are not much changes
>>> in bootstrap time as well as "make check" time.
>> We have about two dozen cases of packages that break when
>> -ftree-vectorize is used.  I'm sure there are several more as we tend to
>> discourage such bug reports.
>>
> If you could take the time to find the reduced testcases and file PRs for
> these, that would be most appreciated.

I believe the majority of them can be traced back to PR 25413.  For
example building zlib with -O2 -march=pentium4 -ftree-vectorize will
cause several apps that link to it (firefox, openoffice, poppler, etc.)
to segfault.  The vectorizer generates movdqa instructions with datarefs
that are not aligned on a 16 byte boundary.

Other than that, I went through the rest of our -ftree-vectorize bugs
this morning and found that many of them have been fixed in 4.2, so the
situation is much better than I originally thought.


-- 
dirtyepic                 salesman said this vacuum's guaranteed
 gentoo org          it could suck an ancient virus from the sea
  9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)

Re: missed vectorization (was Some thoughts about steerring commitee work)

[Tim Prince]

DORIT@il.ibm.com wrote:
> Tim Prince <n8tm@aol.com> wrote on 17/06/2007 04:15:56:
> 
>> hjl@lucon.org wrote:
>>> On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
>>>>> There are quite a few known simple cases which vectorizer fails to
>>>>> vectorize.
>>>> by "known" you mean there are open missed-optimization PRs for them?
> (if
>>> Yes, that is what I meant.
>>>
>> I'd be happy to file some PRs along this line, if there is interest.  C
> 
> yes, there is
> 
>> or C++, if there's more interest in that than in Fortran.  But, gfortran
>> fails to vectorize more than 50% of the stuff I run into every day,
>> including most everything which involves distinct sections of the same
>> array or COMMON block.
> 
> I thought there was already a PR opened for this issue (probably by Toon),
> but I can't find it :-(
> 
> thanks,
> dorit
> 
There are several issues.  EQUIVALENCE produces such a problem (PR32373) 
as do various kinds of references to multiple sections of the same array 
(PR32375,32376,32377,32378,32379,32380).  Only 2 of those PRs involve 
actual source/destination overlap, where the vectorizer would have to 
choose the correct direction (loop reversed or not).
In the bigger case (PR32380) there are loops which vectorize in 
isolation but not in the presence of other loops.

There are existing PRs on a somewhat similar issue involving type 
casting in C. IMHO, not vectorizing those might seem excusable.

Thanks,
Tim

Re: missed vectorization (was Some thoughts about steerring commitee work)

[Janne Blomqvist]

Tim Prince wrote:
> There are several issues.  EQUIVALENCE produces such a problem (PR32373) 
> as do various kinds of references to multiple sections of the same array 
> (PR32375,32376,32377,32378,32379,32380).  Only 2 of those PRs involve 
> actual source/destination overlap, where the vectorizer would have to 
> choose the correct direction (loop reversed or not).
> In the bigger case (PR32380) there are loops which vectorize in 
> isolation but not in the presence of other loops.

Vectorization is tough work, and in the end if you succeed noone cares 
except for the crystallography weenies (and pipe stress freaks, if you 
catch my drift). ;-/

That being said, for the gfortran frontend there are a few things we can 
do to help the vectorizer:

1) Keep our data 16-byte aligned, this could help 32380?. For ALLOCATE 
we could use posix_memalign instead of malloc, if that is available. 
OTOH, AFAIK on x86-64 malloc returns 16-byte aligned so perhaps it's not 
worth bothering about. I'm not sure how to teach the middle-end about 
alignment, but I'm sure there is some way..

2) Annotate variables and procedure interfaces to help the optimizers. I 
think about the only thing we do ATM is declaring pure procedures (incl. 
intrinsics if I read the spaghetti correctly) with DECL_IS_PURE. See 
31094, 31593, 20165, 32131.

3) Better analysis of array syntax. Basically recognizing certain 
patterns and reorganizing the loops so that they can be vectorized. This 
is hard work with limited applicability, and perhaps it's not really 
needed, provided we do (2) well (allowing the middle-end to reorder 
loops if needed)?

-- 
Janne Blomqvist

Re: missed vectorization (was Some thoughts about steerring commitee work)

[Tim Prince]

blomqvist.janne@gmail.com wrote:
> Tim Prince wrote:
>> There are several issues.  EQUIVALENCE produces such a problem 
>> (PR32373) as do various kinds of references to multiple sections of 
>> the same array (PR32375,32376,32377,32378,32379,32380).  Only 2 of 
>> those PRs involve actual source/destination overlap, where the 
>> vectorizer would have to choose the correct direction (loop reversed 
>> or not).
>> In the bigger case (PR32380) there are loops which vectorize in 
>> isolation but not in the presence of other loops.
> 
> Vectorization is tough work, and in the end if you succeed noone cares 
> except for the crystallography weenies (and pipe stress freaks, if you 
> catch my drift). ;-/
> 
> That being said, for the gfortran frontend there are a few things we can 
> do to help the vectorizer:
> 
> 1) Keep our data 16-byte aligned, this could help 32380?. 
In the actual application 32380 is derived from, the initial index is 1 
(16-byte aligned) 99% of the time.  Some of those loops do vectorize 
with gfortran when taken in isolation.  As all the arrays are set the 
same addresses, modulo 32 bytes, any required alignment adjustments for 
the rare cases are the same for all.
Recent public statements indicated that applications like these account 
for >25% of the "server" business of the largest vendors (more than that 
for their competitors), and this fraction is growing.  While this may 
not fit those who use gcc compilers, once the effort has been made to 
support vectorization, it may be of interest to see whether the 
boundaries could be extended.

Re: Some thoughts about steerring commitee work

[Dorit Nuzman]

> Dorit Nuzman wrote:
> >> H. J. Lu wrote:
> >>
> >>> Why don't we turn on vectorizer at -O3 or even -O2, depending on
> >>> ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> >>> -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> >>> gcc source. There are no regressions. There are not much changes
> >>> in bootstrap time as well as "make check" time.
> >> We have about two dozen cases of packages that break when
> >> -ftree-vectorize is used.  I'm sure there are several more as we tend
to
> >> discourage such bug reports.
> >>
> > If you could take the time to find the reduced testcases and file PRs
for
> > these, that would be most appreciated.
>
> I believe the majority of them can be traced back to PR 25413.  For
> example building zlib with -O2 -march=pentium4 -ftree-vectorize will
> cause several apps that link to it (firefox, openoffice, poppler, etc.)
> to segfault.  The vectorizer generates movdqa instructions with datarefs
> that are not aligned on a 16 byte boundary.
>

there is an old patch floating around by Devang to address this problem (as
mentioned in the PR). we should push this forward, it's really a simple
fix. I'll try to get to it soonish

> Other than that, I went through the rest of our -ftree-vectorize bugs
> this morning and found that many of them have been fixed in 4.2, so the
> situation is much better than I originally thought.
>

cool!

thanks,
dorit

>
> --
> dirtyepic                 salesman said this vacuum's guaranteed
>  gentoo org          it could suck an ancient virus from the sea
>   9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8 (0x837937E8)
>

Re: missed vectorization (was Some thoughts about steerring commitee work)

[Dorit Nuzman]

Tim Prince <n8tm@aol.com> wrote on 17/06/2007 19:47:10:

> DORIT@il.ibm.com wrote:
> > Tim Prince <n8tm@aol.com> wrote on 17/06/2007 04:15:56:
> >
> >> hjl@lucon.org wrote:
> >>> On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
> >>>>> There are quite a few known simple cases which vectorizer fails to
> >>>>> vectorize.
> >>>> by "known" you mean there are open missed-optimization PRs for them?
> > (if
> >>> Yes, that is what I meant.
> >>>
> >> I'd be happy to file some PRs along this line, if there is interest.
C
> >
> > yes, there is
> >
> >> or C++, if there's more interest in that than in Fortran.  But,
gfortran
> >> fails to vectorize more than 50% of the stuff I run into every day,
> >> including most everything which involves distinct sections of the same
> >> array or COMMON block.
> >
> > I thought there was already a PR opened for this issue (probably by
Toon),
> > but I can't find it :-(
> >
> > thanks,
> > dorit
> >
> There are several issues.  EQUIVALENCE produces such a problem (PR32373)
> as do various kinds of references to multiple sections of the same array
> (PR32375,32376,32377,32378,32379,32380).  Only 2 of those PRs involve
> actual source/destination overlap, where the vectorizer would have to
> choose the correct direction (loop reversed or not).
> In the bigger case (PR32380) there are loops which vectorize in
> isolation but not in the presence of other loops.
>

thanks for taking the time to extract the testcases and open the PRs. I
guess the discussion can continue in bugzilla now...

> There are existing PRs on a somewhat similar issue involving type
> casting in C. IMHO, not vectorizing those might seem excusable.
>

I think we should teach the vectorizer to handle those as well (another
issue I've been wanting to get to in a while...)

thanks,
dorit

> Thanks,
> Tim

Re: Some thoughts about steerring commitee work

[Mark Mitchell]

Joel Sherrill wrote:

> Note that on the steering committee we represent technical areas
> NOT the companies we work for at any given time.

I'd like to emphasize that this is not only true in theory but in practice.

It is true that, perhaps, when someone from company X is proposed for a
maintainer position there's some bias of SC members from company X to
support that person.  But, I don't think I've ever felt that was out of
putting corporate interests first.  Rather, it was that people from
company X knew the candidate better, felt perceived weaknesses were not
as great as others did, etc.  I have always felt that the SC has been
admirably free of corporate conflict.

I can certainly say that there was no discussion whatsoever of making
sure that Google had "its share" of maintainer representation.  In fact,
the Google-ness of Ian and Diego was not even mentioned.  And, if Ian
and Diego were at some point to leave Google, they would still be
maintainers, but Google won't have any.  I don't think the SC is going
to worry about that.

One advantage of having some SC members who are not GCC developers (and
thus seem less involved) is that they are more independent.  They have
no commercial stake in which companies have maintainers, what
development projects are done by whom, etc.  Presumably, to the extent
they have a vested interest in the outcome it's in making GCC useful for
their own development, which is probably as good a bias as any.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Some thoughts about steerring commitee work

[Toon Moene]

Mark Mitchell wrote:

> One advantage of having some SC members who are not GCC developers (and
> thus seem less involved) is that they are more independent.  They have
> no commercial stake in which companies have maintainers,

The funny part in the discussion on the SC is that most contributors 
seem to place me firmly in the "users" basket, while, at the same time, 
in the Fortran Standardization Committee (http://j3-fortran.org) I'm 
firmly placed in the "vendors" bucket ...

You can please some of the people all of the time and all of the people 
some of the time, but not all of the people all of the time (whose quote 
am I mangling here ?).

BTW, *I* wouldn't be opposed to elections and no-more-years terms for SC 
members.   Part of it is experience in dealing with GCC-within-the-GNU 
project; part of it is experience in developing a great compiler.

Cheers,

-- 
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Who's working on GNU Fortran: 
http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html

Re: Some thoughts about steerring commitee work

[Gerald Pfeifer]

Vladimir,

On Fri, 15 Jun 2007, Vladimir N. Makarov wrote:
> Sorry, it is even make me a bit scary becuase I don't know when the SC 
> decides that we need more maintainers and what maintainers.  When should 
> we propose. After that I am just starting to think who usually propose 
> them.

I know this thread is a bit old, but this part I wanted to respond 
nevertheless (and had kept in my TODO folder therefore).

The SC does not fill the role of the project manager of a regular software 
development project, and as such the SC rarely (if at all) sits down and 
decides that we need more maintainers and what maintainers, not the least 
because, after all, this is a volunteer project.

Maintainers are usually proposed when one of us notices good and ongoing 
contributions by someone, or when someone else (sometimes a maintainer of 
the respective part, sometimes even not a maintainer at all) suggests 
someone else, or someone raises the question him- or herself.  And when
there is a new piece contributed we usually try to find a maintainer from
the beginning, the original contributor(s) being primary candidates.

In other words, if you anyone in mind, please do not hesitate to contact
a SC member of your choice and he will take it from there!

Gerald

PS: I know that we do have a problem with the role of GWP and how these
are being lived and filled (or not).  This is a tough nut that does not
have an easy solution, I'm afraid.