Re: altivec is not the only simd arch

[Aldy Hernandez <aldyh at redhat dot com>]

> > also, i have some in-the-works patches for allowing backends to use
> > the vector modes (V4SI, V2SI, etc) without actually having hardware
> > support for them.
> 
> So you have code in the works to compile altivec code by generating
> non-SIMD instructions?

not exactly, i have code so we can do:

	int foo, bar, zed __attribute__((mode(V4SI)))

	foo = bar;
	zed = foo + bar;

and this will work even if you don't have V4SI in your architecture.
somewhat analogous to having "long long" be 64-bit (DImode), even
if your architecture only does 32-bits.

in the V4SI case, things will get collapsed into a series of SI
instructions.  i'd also like to get it to the point where if you have,
say V2SI, and you want V4SI, gcc can collapse it into V2SI operations
instead of just SI operations.

then there's the other part of my patch that will allow [certain] operators
to work on the SIMD types (=, +, -, *, etc).  this was discussed a while
ago and was accepted on the condition that it be documented and
implemented to behave as VALARRAYS.  i'll be doing that as well.

we can use this for:

	1) hardware support for valarrays
	2) better testing of vector code throughout the compiler
	   since we'll be able to write tests that can be run on
	   any architecture, irregardless of hardware SIMD support.
	3) perhaps provide some building blocks for future vectorization
	   work.

cheers
aldy