This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: auto vectorization in gcc
- From: "Dorit Naishlos" <DORIT at il dot ibm dot com>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: dje at watson dot ibm dot com (David Edelsohn), dnovillo at redhat dot com (Diego Novillo), gcc at gcc dot gnu dot org, law at redhat dot com, matz at suse dot de (Michael Matz), rth at redhat dot com (Richard Henderson)
- Date: Mon, 21 Jul 2003 16:33:20 +0300
- Subject: Re: auto vectorization in gcc
>We need the limit to be machine-dependent, because what is a good vector
size
>for one target, will cause lots of spills for another target (unless you
>want to re-roll the loop, but why should we have to add an extra loop
>re-rolling phase if we can avoid gratituious unrolling in the first place
?).
>Moreover, there is no point in enforcing / preconditioning / checking
>alignment wider than it makes sense for the target.
I agree. I am concerned about the amount of transformation undoing or
redoing
that will be required once we face the limitations/capabilities of the
target
machine in later phases.
dorit
Joern Rennecke
<joern.rennecke@s To: law@redhat.com
uperh.com> cc: matz@suse.de (Michael Matz), gcc@gcc.gnu.org, Dorit Naishlos/Haifa/IBM@IBMIL,
dnovillo@redhat.com (Diego Novillo), dje@watson.ibm.com (David Edelsohn),
17/07/2003 22:35 rth@redhat.com (Richard Henderson)
Subject: Re: auto vectorization in gcc
> What I've always envisioned is that we'd do the vectorization at the tree
> level, building vectors as wide as possible (up to some limit). Then
> at the tree->rtl phase we'd break the vectors down to whatever size the
> target actually supports. The basic idea being to not have a lot of
> target dependencies in the vectorizer.
We need the limit to be machine-dependent, because what is a good vector
size
for one target, will cause lots of spills for another target (unless you
want to re-roll the loop, but why should we have to add an extra loop
re-rolling phase if we can avoid gratituious unrolling in the first place
?).
Moreover, there is no point in enforcing / preconditioning / checking
alignment wider than it makes sense for the target.
If you want to keep the ability to run the tree optimizers target
independetly, we can make the target settings so that they can be
overridden with --param options.