Re: A bit of vector extension documentation

Re: A bit of vector extension documentation

[Bernd Schmidt]

On Thu, 27 Sep 2001, Gerald Pfeifer wrote:

> On Wed, 26 Sep 2001, Bernd Schmidt wrote:
> > Before I check it in - any comments from the regular documentation
> > maintainers?
>
> As far as I can see, this looks fine.

Thanks for looking over it.

> We already have QImode etc. described in rtl.texi; would it make sense
> to unify your descriptions with those resp. add some cross-reference(s)?

I'm not sure about this - do we want to treat the manual as a unit, or do
we want to keep the user and developer parts separated as far as possible?

> + Not all base types or combinations are always valid; which modes can be used
> + is determined by the target machine.  For example, if targetting the i386 MMX
> + extensions, only V8QI, V4HI and V2SI are allowed modes.
>
> Should V8QI etc. become @code{V8QI}?

I suppose they should.

However, I'm still doubtful about exposing a lowlevel interface like
__attribute__((mode)).  So I came up with the patch below, which adds a
new file gcc_vector.h.  This currently provides types for the i386 MMX and
SSE extensions, it can be extended for other CPUs (that's why it's not in
config/i386).

For gcc_vector.h, I copied over the libgcc license - do we have any process
to decide which license to use in cases where the GPL is unlikely to be the
right choice?

I'd like to check in this patch and a modified version of the documentation
patch relatively soon, so if anyone has strong feelings about how we should
expose vector extensions to the user (or about the license issue), please
speak up now.


Bernd

	* config.gcc: For ix86 targets, add gcc_vector.h to extra_headers.
	* config/i386/i386.h (CPP_CPUCOMMON_SPEC): Some new preprocessor
	defines if -mmmx or -msse are enabled.
	* ginclude/gcc_vector.h: New file.

Index: gcc/config.gcc
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config.gcc,v
retrieving revision 1.91
diff -c -p -r1.91 config.gcc
*** config.gcc	2001/09/18 21:51:52	1.91
--- gcc/config.gcc	2001/09/27 14:47:12
*************** case $machine in
*** 3237,3242 ****
--- 3237,3250 ----
  	;;
  esac

+ # Make sure that we provide gcc_vector.h for ix86 systems
+
+ case $machine in
+ i[34567]86-*-*)
+ 	extra_headers=gcc_vector.h
+ 	;;
+ esac
+
  # Distinguish i[34567]86
  # Also, do not run mips-tfile on MIPS if using gas.
  # Process --with-cpu= for PowerPC/rs6000
Index: gcc/config/i386/i386.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/i386.h,v
retrieving revision 1.204
diff -c -p -r1.204 i386.h
*** i386.h	2001/09/21 12:55:17	1.204
--- gcc/config/i386/i386.h	2001/09/27 14:48:36
*************** extern int ix86_arch;
*** 511,516 ****
--- 511,518 ----
  %{mcpu=k6:-D__tune_k6__ }\
  %{mcpu=athlon:-D__tune_athlon__ }\
  %{mcpu=pentium4:-D__tune_pentium4__ }\
+ %{mmmx:-D__MMX_extensions__ }\
+ %{msse:-D__SSE_extensions__ }\
  %{!march*:%{!mcpu*:%{!m386:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}}}}"

  #ifndef CPP_CPU_SPEC
--- /dev/null	Fri Jan 19 09:35:41 2001
+++ gcc/ginclude/gcc_vector.h	Thu Sep 27 11:25:48 2001
@@ -0,0 +1,38 @@
+/* Define the types used by vector extension.  */
+/* Copyright (C) 2001  Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2, or (at your option) any later
+version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING.  If not, write to the Free
+Software Foundation, 59 Temple Place - Suite 330, Boston, MA
+02111-1307, USA.  */
+
+#ifdef __MMX_extensions__
+typedef int v2si __attribute__((mode(V2SI)));
+typedef int v4hi __attribute__((mode(V4HI)));
+typedef int v8qi __attribute__((mode(V8QI)));
+#endif
+#ifdef __SSE_extensions__
+typedef int v4si __attribute__((mode(V4SI)));
+typedef int v4sf __attribute__((mode(V4SF)));
+#endif

Re: A bit of vector extension documentation

[Jan Hubicka]

> 	* ginclude/gcc_vector.h: New file.
Will be there some header to provide Intel C builtins compatibility comming
later?

Honza

Re: A bit of vector extension documentation

[Bernd Schmidt]

On Thu, 27 Sep 2001, Jan Hubicka wrote:

> > 	* ginclude/gcc_vector.h: New file.
> Will be there some header to provide Intel C builtins compatibility comming
> later?

Yes.  But there are many targets which have vector extensions but for which
there is no such established standard, and IMO we should have a relatively
uniform way of accessing vector extensions across different platforms.


Bernd

Re: A bit of vector extension documentation

[Gerald Pfeifer]

On Thu, 27 Sep 2001, Bernd Schmidt wrote:
> I'm not sure about this - do we want to treat the manual as a unit, or do
> we want to keep the user and developer parts separated as far as possible?

Probably separate (at least this was Jeff's plan), but we can refer from
one manual to the other; I forget how exactly this is acomplished, but we
do that somewhere in the installation instructions and I could try to dig
it out if you want.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: A bit of vector extension documentation

[Matt Kraai]

On Thu, Sep 27, 2001 at 04:06:25PM +0100, Bernd Schmidt wrote:
> +In addition to the permissions in the GNU General Public License, the
> +Free Software Foundation gives you unlimited permission to link the
> +compiled version of this file into combinations with other programs,
> +and to distribute those combinations without any restriction coming
> +from the use of this file.  (The General Public License restrictions
> +do apply in other respects; for example, they cover modification of
> +the file, and distribution when not linked into a combine
                                                     ^^^^^^^
> +executable.)

Shouldn't this be `combined'?

Matt

Re: A bit of vector extension documentation

[Daniel Jacobowitz]

On Thu, Sep 27, 2001 at 04:06:25PM +0100, Bernd Schmidt wrote:
> However, I'm still doubtful about exposing a lowlevel interface like
> __attribute__((mode)).  So I came up with the patch below, which adds a
> new file gcc_vector.h.  This currently provides types for the i386 MMX and
> SSE extensions, it can be extended for other CPUs (that's why it's not in
> config/i386).

Why not put it in config/i386 anyway?  That way each architecture which
wants to expose vector types can have its own file, and we won't have
one large cluttered file with special cases for every architecture in
it.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: A bit of vector extension documentation

[Richard Henderson]

On Thu, Sep 27, 2001 at 04:06:25PM +0100, Bernd Schmidt wrote:
> However, I'm still doubtful about exposing a lowlevel interface like
> __attribute__((mode)).

Why not?  We have exposed that interface for quite some time.
It is used in several packages to get a known 32-bit or 64-bit
quantity (yes, I know those packages assume 8-bit chars).

That aside, is it really any better to expose mode(V4SI) as
a typedef named "v4si"?


r~

Re: A bit of vector extension documentation

[Bernd Schmidt]

On Thu, 27 Sep 2001, Richard Henderson wrote:
>
> Why not?  We have exposed that interface for quite some time.
> It is used in several packages to get a known 32-bit or 64-bit
> quantity (yes, I know those packages assume 8-bit chars).

Really?  It's not documented though, and that led me to thinking
it could possibly go away/be replaced in the future.

> That aside, is it really any better to expose mode(V4SI) as
> a typedef named "v4si"?

I'm not too fond of the syntax
  typedef int blah __attribute__((mode(xxx)));
mainly because the "int" gets ignored.  It just seems quirky.  But if no
one else sees a problem with it, I'll stick to the original documentation
I wrote.


Bernd

Re: A bit of vector extension documentation

[Richard Henderson]

On Thu, Sep 27, 2001 at 08:37:29PM +0100, Bernd Schmidt wrote:
> Really?  It's not documented though, and that led me to thinking
> it could possibly go away/be replaced in the future.

Yes it is.  Under "@node Variable Attributes" in extend.texi.


r~

Re: A bit of vector extension documentation

[Bernd Schmidt]

On Thu, 27 Sep 2001, Richard Henderson wrote:

> On Thu, Sep 27, 2001 at 08:37:29PM +0100, Bernd Schmidt wrote:
> > Really?  It's not documented though, and that led me to thinking
> > it could possibly go away/be replaced in the future.
>
> Yes it is.  Under "@node Variable Attributes" in extend.texi.

Oh darn.  I grepped for "attribute.*mode" :-/


Bernd

Re: A bit of vector extension documentation

[Daniel Egger]

On Don, 2001-09-27 at 17:06, Bernd Schmidt wrote:

> However, I'm still doubtful about exposing a lowlevel interface like
> __attribute__((mode)).  So I came up with the patch below, which adds a
> new file gcc_vector.h.  This currently provides types for the i386 MMX and
> SSE extensions, it can be extended for other CPUs (that's why it's not in
> config/i386).

I'm actually more concerned about the braindead interface to those functions.
Using __bultin_whatever to apply single operations to SIMD types is about
as comfortable as inline ASM programming at large with the advantage of
scheduling.

--
Servus,
       Daniel

Re: A bit of vector extension documentation

[Richard Henderson]

On Fri, Sep 28, 2001 at 09:03:57AM +0200, Daniel Egger wrote:
> I'm actually more concerned about the braindead interface to those functions.
> Using __bultin_whatever to apply single operations to SIMD types is about
> as comfortable as inline ASM programming at large with the advantage of
> scheduling.

So wrap it in something.


r~


class v4sf
{
  public:
    typedef int vector __attribute__((mode(V4SF)));

  private:
    union {
      vector v;
      float a[4];
    };

  public:
    v4sf(float w, float x, float y, float z) {
      a[0] = w;
      a[1] = x;
      a[2] = y;
      a[3] = z;
    }

    v4sf(vector x) {
      v = x;
    }

    v4sf(const v4sf &other) {
      v = other.v;
    }

    v4sf operator + (const v4sf &other) {
      return v4sf(__builtin_vec_add(v, other.v));
    }
};

Re: A bit of vector extension documentation

[Daniel Egger]

On Fre, 2001-09-28 at 09:38, Richard Henderson wrote:

> So wrap it in something.

Although being able to hack OO languages like C++ and Java
I prefer C for my daily work and it's not acceptable for
some project to introduce C++ - especially for the sole purpose
of only being compilable with most recent GCC versions and
C++ frontend; though you clearly demonstrate what I would expect
to have in the gcc compilersuite somewhere in a templateized
version for general use.

At the moment I'm using the vector extensions from Motorola for
my Altivec coding and although I understand that it might not
be acceptable to introduce something similar into GCC because
it breaks source compatibility in subtle ways I will keep on
using this special 2.95.3 around to generate scheduled ASM
code which I can easily include in applications.

For the future I'd expect to have something like a heuristic that
figures out that loops are trying to do some operations on MD that
is parallelizable and generate good SIMD code for it when the necessary
switch is flipped; yes, this will break applications when one tries to
run them on unwary processors like -mcpu=i686 breaks for i586 and it
might not be desirable in all places especially on Intel CPU where the
cost for switching between SIMD and normal FPU operation is quite costly
but this is for sure the future. There are already compilers out there
which work exactly like described (was it called VAST?) so it seems not
to be completely impossible.

--
Servus,
       Daniel

Re: A bit of vector extension documentation

[Richard Henderson]

On Fri, Sep 28, 2001 at 10:00:05AM +0200, Daniel Egger wrote:
> Although being able to hack OO languages like C++ and Java
> I prefer C for my daily work and it's not acceptable for
> some project to introduce C++ - especially for the sole purpose
> of only being compilable with most recent GCC versions and
> C++ frontend;

Judicious local use of macros or static inline functions can
rid you of some of the uglier "__builtin" parts.

> ... though you clearly demonstrate what I would expect
> to have in the gcc compilersuite somewhere in a templateized
> version for general use.

Yes, we should definitely distribute something of the sort.

> For the future I'd expect to have something like a heuristic that
> figures out that loops are trying to do some operations on MD that
> is parallelizable and generate good SIMD code for it ...

This is on the wish list.  But even if someone were to start on
it now, I can't see it being complete for at least a year.  Some
of the prerequisites are being worked on though -- see the AST
branch.


r~

Re: A bit of vector extension documentation

[Daniel Egger]

On Fre, 2001-09-28 at 10:32, Richard Henderson wrote:

> Judicious local use of macros or static inline functions can
> rid you of some of the uglier "__builtin" parts.

I'll play around with it and try whether I can mock something
up that is not too ugly for my personal taste.

> > ... though you clearly demonstrate what I would expect
> > to have in the gcc compilersuite somewhere in a templateized
> > version for general use.
 
> Yes, we should definitely distribute something of the sort.

Is anyone already working on it?

> This is on the wish list.  But even if someone were to start on
> it now, I can't see it being complete for at least a year.  Some
> of the prerequisites are being worked on though -- see the AST
> branch.

Thanks for the points, I'll do that.

BTW: How about the latest documentation fix I posted. Is it ok for
checkin or should I redo it; do you want a ChangeLog entry?

--
Servus,
       Daniel

Re: A bit of vector extension documentation

[Daniel Berlin]

On Friday, September 28, 2001, at 04:32  AM, Richard Henderson wrote:

> On Fri, Sep 28, 2001 at 10:00:05AM +0200, Daniel Egger wrote:
>> Although being able to hack OO languages like C++ and Java
>> I prefer C for my daily work and it's not acceptable for
>> some project to introduce C++ - especially for the sole purpose
>> of only being compilable with most recent GCC versions and
>> C++ frontend;
>
> Judicious local use of macros or static inline functions can
> rid you of some of the uglier "__builtin" parts.
>
>> ... though you clearly demonstrate what I would expect
>> to have in the gcc compilersuite somewhere in a templateized
>> version for general use.
>
> Yes, we should definitely distribute something of the sort.
>
>> For the future I'd expect to have something like a heuristic that
>> figures out that loops are trying to do some operations on MD that
>> is parallelizable and generate good SIMD code for it ...
>
> This is on the wish list.  But even if someone were to start on
> it now, I can't see it being complete for at least a year.  Some
> of the prerequisites are being worked on though -- see the AST
> branch.
>
A year, eh?
I actually have it half-done (I only did it for integer calculations), 
and working (though not thoroughly tested).
It's based on the algorithms in the paper "Exploiting superword level 
parallelism with multimedia instruction sets"
http://www.acm.org/pubs/citations/proceedings/pldi/349299/p145-larsen/

It's not tricky at all to do, it just requires proper dependence and 
alignment analysis.

I'll happily hand it off to someone who wants to complete it.

>
> r~

Re: A bit of vector extension documentation

[Richard Henderson]

On Fri, Sep 28, 2001 at 11:48:31AM -0400, Daniel Berlin wrote:
> It's based on the algorithms in the paper "Exploiting superword level 
> parallelism with multimedia instruction sets"
> http://www.acm.org/pubs/citations/proceedings/pldi/349299/p145-larsen/

Yes, I've seen that one.  While a nice starting point, I don't 
think it's as powerful as some of the other loop-based vectorization
algorithms.



r~

Re: A bit of vector extension documentation

[David Edelsohn]

>>>>> Richard Henderson writes:

Richard> On Fri, Sep 28, 2001 at 11:48:31AM -0400, Daniel Berlin wrote:
>> It's based on the algorithms in the paper "Exploiting superword level 
>> parallelism with multimedia instruction sets"
>> http://www.acm.org/pubs/citations/proceedings/pldi/349299/p145-larsen/

Richard> Yes, I've seen that one.  While a nice starting point, I don't 
Richard> think it's as powerful as some of the other loop-based vectorization
Richard> algorithms.

	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.

David

Re: A bit of vector extension documentation

[Diego Novillo]

On Fri, 28 Sep 2001, David Edelsohn wrote:

> >>>>> Richard Henderson writes:
> 
> Richard> On Fri, Sep 28, 2001 at 11:48:31AM -0400, Daniel Berlin wrote:
> >> It's based on the algorithms in the paper "Exploiting superword level 
> >> parallelism with multimedia instruction sets"
> >> http://www.acm.org/pubs/citations/proceedings/pldi/349299/p145-larsen/
> 
> Richard> Yes, I've seen that one.  While a nice starting point, I don't 
> Richard> think it's as powerful as some of the other loop-based vectorization
> Richard> algorithms.
> 
> 	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.

Diego.

Re: A bit of vector extension documentation

[Toon Moene]

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) ?

Consider

      DO I = 1, N
         A(I) = B(I) + C(I)
      ENDDO

and its unrolled cousin

      DO I = 1, N, 4
         A(I+0) = B(I+0) + C(I+0)
         A(I+1) = B(I+1) + C(I+1)
         A(I+2) = B(I+2) + C(I+2)
         A(I+3) = B(I+3) + C(I+3)
      ENDDO

Certainly the loop body in both examples is a single basic block.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: A bit of vector extension documentation

[Diego Novillo]

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.

Re: A bit of vector extension documentation

[Tim Prince]

To make it pay off on the Intel SIMD architectures, the compiler
must be able to analyze alignments, allocate arrays on 16-byte
boundaries, and pre-condition loops so that a majority of
operands are 16-byte aligned in the unrolled body of the loop.
Maybe this fits with the typical programming practice of writing
specific code for each architecture when the loops are just the
size of a SIMD instruction, and looking for compiler
vectorization of loops which conform to standard syntax when they
are believed to be long enough.
----- Original Message -----
From: "Toon Moene" <toon@moene.indiv.nluug.nl>
To: "Diego Novillo" <dnovillo@redhat.com>
Cc: "David Edelsohn" <dje@watson.ibm.com>; "Richard Henderson"
<rth@redhat.com>; "Daniel Berlin" <dan@cgsoftware.com>; "Daniel
Egger" <degger@fhm.edu>; <gcc-patches@gcc.gnu.org>;
<gcc@gcc.gnu.org>
Sent: Friday, September 28, 2001 12:12 PM
Subject: Re: A bit of vector extension documentation


> 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) ?
>
> Consider
>
>       DO I = 1, N
>          A(I) = B(I) + C(I)
>       ENDDO
>
> and its unrolled cousin
>
>       DO I = 1, N, 4
>          A(I+0) = B(I+0) + C(I+0)
>          A(I+1) = B(I+1) + C(I+1)
>          A(I+2) = B(I+2) + C(I+2)
>          A(I+3) = B(I+3) + C(I+3)
>       ENDDO
>
> Certainly the loop body in both examples is a single basic
block.
>
> --
> Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31
346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> Maintainer, GNU Fortran 77:
http://gcc.gnu.org/onlinedocs/g77_news.html
> Join GNU Fortran 95: http://g95.sourceforge.net/ (under
construction)

Re: A bit of vector extension documentation

[Aldy Hernandez]

>>>>> "Tim" == Tim Prince <tprince@computer.org> writes:

 > To make it pay off on the Intel SIMD architectures, the compiler
 > must be able to analyze alignments, allocate arrays on 16-byte
 > boundaries, and pre-condition loops so that a majority of

same thing for altivec stuff.  It all needs to be 16 byte aligned.

Aldy

Re: A bit of vector extension documentation

[Daniel Berlin]

Diego Novillo <dnovillo@redhat.com> writes:

> On Fri, 28 Sep 2001, David Edelsohn wrote:
>
>> >>>>> Richard Henderson writes:
>> 
>> Richard> On Fri, Sep 28, 2001 at 11:48:31AM -0400, Daniel Berlin wrote:
>> >> It's based on the algorithms in the paper "Exploiting superword level 
>> >> parallelism with multimedia instruction sets"
>> >> http://www.acm.org/pubs/citations/proceedings/pldi/349299/p145-larsen/
>> 
>> Richard> Yes, I've seen that one.  While a nice starting point, I don't 
>> Richard> think it's as powerful as some of the other loop-based vectorization
>> Richard> algorithms.
>> 
>> 	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.
Sure, but this includes basic blocks inside loops.
Won't this take care of the majority of cases anyway?
>
> Diego.

-- 
"Everywhere is walking distance if you have the time.
"-Steven Wright

Re: A bit of vector extension documentation

[Daniel Berlin]

On Friday, September 28, 2001, at 12:38  PM, Richard Henderson wrote:

> On Fri, Sep 28, 2001 at 11:48:31AM -0400, Daniel Berlin wrote:
>> It's based on the algorithms in the paper "Exploiting superword level
>> parallelism with multimedia instruction sets"
>> http://www.acm.org/pubs/citations/proceedings/pldi/349299/p145-larsen/
>
> Yes, I've seen that one.  While a nice starting point, I don't
> think it's as powerful as some of the other loop-based vectorization
> algorithms.
I'm curious what makes you say that.
It actually should be more powerful than loop based vectorization 
algorithms.
Except maybe in some very specialized cases.
>
>
>
> r~

Re: A bit of vector extension documentation

[Richard Henderson]

On Fri, Sep 28, 2001 at 01:07:32PM -0400, Daniel Berlin wrote:
> Except maybe in some very specialized cases.

I suspect those specialized cases are actually the
majority of the kernels folks care about.


r~