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
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
Interesting. I
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
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
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. Please do
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 model
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
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
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-optimization PRs for
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
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 it
sha1 is
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
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
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 82 loops
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,
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
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
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
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).
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
happens. It
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 LLVM,
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
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.
[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 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.
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
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
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.
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
which are not
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
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
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
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
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 those charts a
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 by the other
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.
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
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
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 committee was
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
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.
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
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
45 matches
Mail list logo
