This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Some thoughts about steerring commitee work
- From: Dorit Nuzman <DORIT at il dot ibm dot com>
- To: "Vladimir N. Makarov" <vmakarov at redhat dot com>
- Cc: Eric Botcazou <ebotcazou at libertysurf dot fr>, gcc at gcc dot gnu dot org, "H. J. Lu" <hjl at lucon dot org>, Ian Lance Taylor <iant at google dot com>
- Date: Sat, 16 Jun 2007 18:51:46 +0300
- Subject: Re: Some thoughts about steerring commitee work
> 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
>