conversions between vectors

[Aldy Hernandez]

> > Compatability with valarray is a nice thought, but I don't think it's
> > quite relevant.  In documenting valarrays and C-vectors, we'll find
> > more differences than similarities.
> 
> Valarrays tell you that you can't operate between vectors of different
> lengths.  They tell you what types of operands you can operate on, with

but as i understand, you can't operate between vectors of the same size
either. (signed vs unsigned)

the problem i see is that we're trying to push a c++ish extension to fit
into C semantics, just because that particular c++ extension has been
known to work.

> additions need to be done with very great care.  Are you sure these vector
> extensions will never be used in safety-critical systems?  Implicit

then we should outlaw pointers, to have the safety of programmers in
mind.

> non-value-preserving conversions are a source of complexity, and of risk
> if everyone involved doesn't have a full understanding of the conversions,

we can document that we allow signed and unsigned assignments.  that's
not a problem.  i doubt it'll come to anyone's surpprise.

> what type everything has and where the conversions are applying.  At least
> with valarray we have a design that has already been worked out and some

is there some documentation for valarray?  i'd like to read more on it.

my biggest beef is, say __builtin_vector_add_v4si

	vector int a, b, c;

	c = __builtin_vector_add_v4si (a, b);

if sign is not automatically converted, then we would need a
corresponding:

	c2 = __builtin_vector_add_v4si_unsigned (a2, b2);

even if both builtins map to the same exact machine instruction.

i suppose we can force the programmer to do:

	c2 = (vector signed int) __builtin_vector_add_v4si
		((vector signed int) a2, (vector signed int) b2);

but that's precisely my point.  do we really want to force such casts
for something that should just work?

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.