This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: auto vectorization in gcc
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: law at redhat dot com
- Cc: matz at suse dot de (Michael Matz), gcc at gcc dot gnu dot org, DORIT at il dot ibm dot com (Dorit Naishlos), dnovillo at redhat dot com (Diego Novillo), dje at watson dot ibm dot com (David Edelsohn), rth at redhat dot com (Richard Henderson)
- Date: Thu, 17 Jul 2003 20:35:05 +0100 (BST)
- 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.