This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A bit of vector extension documentation
- To: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Subject: Re: A bit of vector extension documentation
- From: Diego Novillo <dnovillo at redhat dot com>
- Date: Fri, 28 Sep 2001 15:45:12 -0400
- Cc: David Edelsohn <dje at watson dot ibm dot com>, Richard Henderson <rth at redhat dot com>, Daniel Berlin <dan at cgsoftware dot com>, Daniel Egger <degger at fhm dot edu>, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Organization: Red Hat Canada
- References: <rth@redhat.com> <200109281712.NAA23750@makai.watson.ibm.com> <20010928132532.A10203@tornado.cygnus.com> <3BB4CB8E.DF6B40F4@moene.indiv.nluug.nl>
On Fri, 28 Sep 2001, Toon Moene wrote:
> Diego Novillo wrote:
>
> > On Fri, 28 Sep 2001, David Edelsohn wrote:
>
> > > I thought the point of the paper is that it is a generalization
> > > that does not require loops. For SIMD, as opposed to vector,
> > > architectures, it might be better because it can take advantage of such
> > > instructions without the loop setup overhead.
> > >
> > Yes, the paper does not attempt to design a vectorizing compiler.
> > It merely points out that in several cases you can get away with
> > converting sequence of expressions into SIMD instructions. They
> > do have the limitation of working on single basic blocks, though.
>
> Hmmm, wouldn't that already help on most of the interesting Fortran
> loops, when unrolled (i.e., when "converting sequences of expressions
> into SIMD instructions" is performed after loop unrolling) ?
>
Oh, most definitely. It was just an observation of an obvious
extension to their work. If the analysis is globalized you can
minimize the overhead of packing/unpacking the vector instructions
at block boundaries (if you can re-use a previous packing, for
instance).
The ideas in the paper are certainly interesting and I think
could be put to very good use in GCC.
Diego.