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
> 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.
Sorry for the late replay.
The devirtualization is on hold. Currently GCC is lacking the necessary
infrastructure needed by C
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
see
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
maintaine
Hi Dorit,
>loop-context when it helps you do things more efficiently. In any case,
>we'll have to have a much better cost model before we start packing
random
>sequences of stmts out of loops.
This is off topic from the discussion at hand, but we would be happy to
help with changing the cost mode
On 6/18/07, Sebastian Pop <[EMAIL PROTECTED]> wrote:
On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> > I can hand you more than the testcases i've given so far. There is
> > tons of code out there that would benefit from straight line
>
> Interesting. I wasn't aware of this potential. Ple
On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> I can hand you more than the testcases i've given so far. There is
> tons of code out there that would benefit from straight line
Interesting. I wasn't aware of this potential. Please do send some of this
code. thanks!
I'm thinking about
I can hand you more than the testcases i've given so far. There is
tons of code out there that would benefit from straight line
vectorization.
I'm interested in these test cases. Thanks!
In fact, we have some that gets written in loop form
right now just so it gets vectorized!
May be loop
>
> > However, as far as I know (also from talking with the
> > SLP authors) pretty much all the opportunities they had found at the
time
> > were in loops.
>
> I can hand you more than the testcases i've given so far. There is
> tons of code out there that would benefit from straight line
Inter
On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 17/06/2007 18:18:19:
...
>
> The whole purpose of SLP was to enable straight line code
> vectorization outside of loops.
I wouldn't say that's the whole purpose of SLP.
Okay, that is probably a st
Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 19:47:10:
> [EMAIL PROTECTED] wrote:
> > Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:
> >
> >> [EMAIL PROTECTED] wrote:
> >>> On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
> > There are quite a few known simple
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 17/06/2007 18:18:19:
...
>
> The whole purpose of SLP was to enable straight line code
> vectorization outside of loops.
I wouldn't say that's the whole purpose of SLP. I think the purpose and
beauty of SLP is that it's a simple algorithm that makes ve
> 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 regres
[EMAIL PROTECTED] 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,
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
[EMAIL PROTECTED] wrote:
Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:
[EMAIL PROTECTED] 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
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 a
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
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 16/06/2007:
> On 6/16/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
>
> > 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
> 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
>
Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:
> [EMAIL PROTECTED] 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-optimiz
[EMAIL PROTECTED] 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
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.
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 bootstra
On Sat, Jun 16, 2007 at 04:02:39AM +0200, J.C. Pizarro wrote:
> Please, to see
>
> 1. "The LLVM Compiler System" by Chris Lattner
You have posted essentially the same message three times on three
different threads. Chris Lattner himself has asked you to stop.
If you'd prefer to use or work on L
On 6/16/07, Dorit Nuzman <[EMAIL PROTECTED]> 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
> happ
> 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 SPECInt20
> 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 lo
> 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
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 fe
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 bef
On Fri, Jun 15, 2007 at 07:17:22PM -0700, Andrew Pinski wrote:
> On 6/15/07, H. J. Lu <[EMAIL PROTECTED]> 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
> 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 d
> 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 oft
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
al
> The optimizing stages of GCC's backend are big, fragmented and complex.
>
> I think that the GCC's commitee goes to the wrong direction.
The steering committee doesn't make those sorts of technical directions.
Moreover, nearly all of the backend of GCC existed before the steering
committee was
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.
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
han
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> The optimizing stages of GCC's backend are big, fragmented and complex.
>
> I think that the GCC's commitee goes to the wrong direction.
It's an error to blame the steering committee for the ugliness of
gcc's optimization passes. The steering committ
On 6/15/07, H. J. Lu <[EMAIL PROTECTED]> 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
Please, to see
1. "The LLVM Compiler System" by Chris Lattner
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html
http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf
2. "Vector LLVA: A Virtual Vector Instruction Set for Media Processing"
by Bocchino and Vikram
http://llvm.org/pubs/2006-06-15-VEE-
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.
"Vladimir N. Makarov" <[EMAIL PROTECTED]> 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
Eric Botcazou <[EMAIL PROTECTED]> 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 th
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,
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
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 data
> 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, *nobod
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
On 6/15/07, Eric Botcazou <[EMAIL PROTECTED]> 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
> 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
tha
Ian Lance Taylor wrote:
"Vladimir N. Makarov" <[EMAIL PROTECTED]> 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 ar
"Vladimir N. Makarov" <[EMAIL PROTECTED]> 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
> >w
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
"Vladimir N. Makarov" <[EMAIL PROTECTED]> 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
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
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 memb
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 role
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 kn
> 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 mem
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
61 matches
Mail list logo
