* Re: A bit of vector extension documentation [not found] <Pine.BSF.4.33.0109271622590.737-100000@naos.dbai.tuwien.ac.at> @ 2001-09-27 8:06 ` Bernd Schmidt 2001-09-27 8:24 ` Jan Hubicka ` (5 more replies) 0 siblings, 6 replies; 26+ messages in thread From: Bernd Schmidt @ 2001-09-27 8:06 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: gcc-patches, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 8:06 ` A bit of vector extension documentation Bernd Schmidt @ 2001-09-27 8:24 ` Jan Hubicka 2001-09-27 8:45 ` Bernd Schmidt 2001-09-27 8:32 ` Gerald Pfeifer ` (4 subsequent siblings) 5 siblings, 1 reply; 26+ messages in thread From: Jan Hubicka @ 2001-09-27 8:24 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Gerald Pfeifer, gcc-patches, gcc > * ginclude/gcc_vector.h: New file. Will be there some header to provide Intel C builtins compatibility comming later? Honza ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 8:24 ` Jan Hubicka @ 2001-09-27 8:45 ` Bernd Schmidt 0 siblings, 0 replies; 26+ messages in thread From: Bernd Schmidt @ 2001-09-27 8:45 UTC (permalink / raw) To: Jan Hubicka; +Cc: Gerald Pfeifer, gcc-patches, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 8:06 ` A bit of vector extension documentation Bernd Schmidt 2001-09-27 8:24 ` Jan Hubicka @ 2001-09-27 8:32 ` Gerald Pfeifer 2001-09-27 9:04 ` Matt Kraai ` (3 subsequent siblings) 5 siblings, 0 replies; 26+ messages in thread From: Gerald Pfeifer @ 2001-09-27 8:32 UTC (permalink / raw) To: Bernd Schmidt; +Cc: gcc-patches, gcc 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 8:06 ` A bit of vector extension documentation Bernd Schmidt 2001-09-27 8:24 ` Jan Hubicka 2001-09-27 8:32 ` Gerald Pfeifer @ 2001-09-27 9:04 ` Matt Kraai 2001-09-27 11:34 ` Daniel Jacobowitz ` (2 subsequent siblings) 5 siblings, 0 replies; 26+ messages in thread From: Matt Kraai @ 2001-09-27 9:04 UTC (permalink / raw) To: Bernd Schmidt; +Cc: gcc-patches, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 8:06 ` A bit of vector extension documentation Bernd Schmidt ` (2 preceding siblings ...) 2001-09-27 9:04 ` Matt Kraai @ 2001-09-27 11:34 ` Daniel Jacobowitz 2001-09-27 12:33 ` Richard Henderson 2001-09-28 0:05 ` Daniel Egger 5 siblings, 0 replies; 26+ messages in thread From: Daniel Jacobowitz @ 2001-09-27 11:34 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Gerald Pfeifer, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 8:06 ` A bit of vector extension documentation Bernd Schmidt ` (3 preceding siblings ...) 2001-09-27 11:34 ` Daniel Jacobowitz @ 2001-09-27 12:33 ` Richard Henderson 2001-09-27 12:37 ` Bernd Schmidt 2001-09-28 0:05 ` Daniel Egger 5 siblings, 1 reply; 26+ messages in thread From: Richard Henderson @ 2001-09-27 12:33 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Gerald Pfeifer, gcc-patches, gcc 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~ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 12:33 ` Richard Henderson @ 2001-09-27 12:37 ` Bernd Schmidt 2001-09-27 12:44 ` Richard Henderson 0 siblings, 1 reply; 26+ messages in thread From: Bernd Schmidt @ 2001-09-27 12:37 UTC (permalink / raw) To: Richard Henderson; +Cc: Gerald Pfeifer, gcc-patches, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 12:37 ` Bernd Schmidt @ 2001-09-27 12:44 ` Richard Henderson 2001-09-27 12:45 ` Bernd Schmidt 0 siblings, 1 reply; 26+ messages in thread From: Richard Henderson @ 2001-09-27 12:44 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Gerald Pfeifer, gcc-patches, gcc 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~ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 12:44 ` Richard Henderson @ 2001-09-27 12:45 ` Bernd Schmidt 0 siblings, 0 replies; 26+ messages in thread From: Bernd Schmidt @ 2001-09-27 12:45 UTC (permalink / raw) To: Richard Henderson; +Cc: Gerald Pfeifer, gcc-patches, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-27 8:06 ` A bit of vector extension documentation Bernd Schmidt ` (4 preceding siblings ...) 2001-09-27 12:33 ` Richard Henderson @ 2001-09-28 0:05 ` Daniel Egger 2001-09-28 0:39 ` Richard Henderson 5 siblings, 1 reply; 26+ messages in thread From: Daniel Egger @ 2001-09-28 0:05 UTC (permalink / raw) To: Bernd Schmidt; +Cc: gcc-patches, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 0:05 ` Daniel Egger @ 2001-09-28 0:39 ` Richard Henderson 2001-09-28 0:59 ` Daniel Egger 0 siblings, 1 reply; 26+ messages in thread From: Richard Henderson @ 2001-09-28 0:39 UTC (permalink / raw) To: Daniel Egger; +Cc: Bernd Schmidt, gcc-patches, gcc 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)); } }; ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 0:39 ` Richard Henderson @ 2001-09-28 0:59 ` Daniel Egger 2001-09-28 1:32 ` Richard Henderson 0 siblings, 1 reply; 26+ messages in thread From: Daniel Egger @ 2001-09-28 0:59 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc-patches, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 0:59 ` Daniel Egger @ 2001-09-28 1:32 ` Richard Henderson 2001-09-28 1:56 ` Daniel Egger 2001-09-28 8:48 ` Daniel Berlin 0 siblings, 2 replies; 26+ messages in thread From: Richard Henderson @ 2001-09-28 1:32 UTC (permalink / raw) To: Daniel Egger; +Cc: gcc-patches, gcc 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~ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 1:32 ` Richard Henderson @ 2001-09-28 1:56 ` Daniel Egger 2001-09-28 8:48 ` Daniel Berlin 1 sibling, 0 replies; 26+ messages in thread From: Daniel Egger @ 2001-09-28 1:56 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 1:32 ` Richard Henderson 2001-09-28 1:56 ` Daniel Egger @ 2001-09-28 8:48 ` Daniel Berlin 2001-09-28 9:38 ` Richard Henderson 1 sibling, 1 reply; 26+ messages in thread From: Daniel Berlin @ 2001-09-28 8:48 UTC (permalink / raw) To: Richard Henderson; +Cc: Daniel Egger, gcc-patches, gcc 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~ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 8:48 ` Daniel Berlin @ 2001-09-28 9:38 ` Richard Henderson 2001-09-28 10:13 ` David Edelsohn 2001-09-29 17:11 ` Daniel Berlin 0 siblings, 2 replies; 26+ messages in thread From: Richard Henderson @ 2001-09-28 9:38 UTC (permalink / raw) To: Daniel Berlin; +Cc: Daniel Egger, gcc-patches, gcc 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~ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 9:38 ` Richard Henderson @ 2001-09-28 10:13 ` David Edelsohn 2001-09-28 10:25 ` Diego Novillo 2001-09-29 17:11 ` Daniel Berlin 1 sibling, 1 reply; 26+ messages in thread From: David Edelsohn @ 2001-09-28 10:13 UTC (permalink / raw) To: Richard Henderson; +Cc: Daniel Berlin, Daniel Egger, gcc-patches, gcc >>>>> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 10:13 ` David Edelsohn @ 2001-09-28 10:25 ` Diego Novillo 2001-09-28 12:11 ` Toon Moene 2001-09-28 15:37 ` Daniel Berlin 0 siblings, 2 replies; 26+ messages in thread From: Diego Novillo @ 2001-09-28 10:25 UTC (permalink / raw) To: David Edelsohn Cc: Richard Henderson, Daniel Berlin, Daniel Egger, gcc-patches, gcc 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 10:25 ` Diego Novillo @ 2001-09-28 12:11 ` Toon Moene 2001-09-28 12:45 ` Diego Novillo 2001-09-28 13:21 ` Tim Prince 2001-09-28 15:37 ` Daniel Berlin 1 sibling, 2 replies; 26+ messages in thread From: Toon Moene @ 2001-09-28 12:11 UTC (permalink / raw) To: Diego Novillo Cc: David Edelsohn, Richard Henderson, Daniel Berlin, Daniel Egger, gcc-patches, gcc 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) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 12:11 ` Toon Moene @ 2001-09-28 12:45 ` Diego Novillo 2001-09-28 13:21 ` Tim Prince 1 sibling, 0 replies; 26+ messages in thread From: Diego Novillo @ 2001-09-28 12:45 UTC (permalink / raw) To: Toon Moene Cc: David Edelsohn, Richard Henderson, Daniel Berlin, Daniel Egger, gcc-patches, gcc 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 12:11 ` Toon Moene 2001-09-28 12:45 ` Diego Novillo @ 2001-09-28 13:21 ` Tim Prince 2001-09-29 14:33 ` Aldy Hernandez 1 sibling, 1 reply; 26+ messages in thread From: Tim Prince @ 2001-09-28 13:21 UTC (permalink / raw) To: Toon Moene, Diego Novillo Cc: David Edelsohn, Richard Henderson, Daniel Berlin, Daniel Egger, gcc-patches, gcc 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) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 13:21 ` Tim Prince @ 2001-09-29 14:33 ` Aldy Hernandez 0 siblings, 0 replies; 26+ messages in thread From: Aldy Hernandez @ 2001-09-29 14:33 UTC (permalink / raw) To: Tim Prince Cc: Toon Moene, Diego Novillo, David Edelsohn, Richard Henderson, Daniel Berlin, Daniel Egger, gcc-patches, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 10:25 ` Diego Novillo 2001-09-28 12:11 ` Toon Moene @ 2001-09-28 15:37 ` Daniel Berlin 1 sibling, 0 replies; 26+ messages in thread From: Daniel Berlin @ 2001-09-28 15:37 UTC (permalink / raw) To: Diego Novillo Cc: David Edelsohn, Richard Henderson, Daniel Berlin, Daniel Egger, gcc-patches, gcc 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-28 9:38 ` Richard Henderson 2001-09-28 10:13 ` David Edelsohn @ 2001-09-29 17:11 ` Daniel Berlin 2001-09-29 19:37 ` Richard Henderson 1 sibling, 1 reply; 26+ messages in thread From: Daniel Berlin @ 2001-09-29 17:11 UTC (permalink / raw) To: Richard Henderson; +Cc: Daniel Egger, gcc-patches, gcc 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~ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A bit of vector extension documentation 2001-09-29 17:11 ` Daniel Berlin @ 2001-09-29 19:37 ` Richard Henderson 0 siblings, 0 replies; 26+ messages in thread From: Richard Henderson @ 2001-09-29 19:37 UTC (permalink / raw) To: Daniel Berlin; +Cc: Daniel Egger, gcc-patches, gcc 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~ ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2001-09-29 19:37 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Pine.BSF.4.33.0109271622590.737-100000@naos.dbai.tuwien.ac.at> 2001-09-27 8:06 ` A bit of vector extension documentation Bernd Schmidt 2001-09-27 8:24 ` Jan Hubicka 2001-09-27 8:45 ` Bernd Schmidt 2001-09-27 8:32 ` Gerald Pfeifer 2001-09-27 9:04 ` Matt Kraai 2001-09-27 11:34 ` Daniel Jacobowitz 2001-09-27 12:33 ` Richard Henderson 2001-09-27 12:37 ` Bernd Schmidt 2001-09-27 12:44 ` Richard Henderson 2001-09-27 12:45 ` Bernd Schmidt 2001-09-28 0:05 ` Daniel Egger 2001-09-28 0:39 ` Richard Henderson 2001-09-28 0:59 ` Daniel Egger 2001-09-28 1:32 ` Richard Henderson 2001-09-28 1:56 ` Daniel Egger 2001-09-28 8:48 ` Daniel Berlin 2001-09-28 9:38 ` Richard Henderson 2001-09-28 10:13 ` David Edelsohn 2001-09-28 10:25 ` Diego Novillo 2001-09-28 12:11 ` Toon Moene 2001-09-28 12:45 ` Diego Novillo 2001-09-28 13:21 ` Tim Prince 2001-09-29 14:33 ` Aldy Hernandez 2001-09-28 15:37 ` Daniel Berlin 2001-09-29 17:11 ` Daniel Berlin 2001-09-29 19:37 ` Richard Henderson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).