> "Vector types can be cast to other vector types. The cast does not
> perform a conversion: it preserves the 128-bit pattern, but not
> necessarily the value. A cast between a vector type and a scalar type is
> not allowed."
Everything becomes clear. I would never have started this thread of
I'd realized there was a spec somewhere. There doesn't seem to be any
way to discover this stuff by reading the gcc docs.
Well, what I cited is the XLC manual. So the gcc docs could use some
improvement, yes.
> > Secondly, can we fix it?
>
> We can do anything we want. Or we can do nothing -- it depends on the
> point of view. :-) While looking at PR10735, one or two years ago I set
> to implement some rules resembling the ones outlined by Ian, only to
> find that I would break the Altivec tests in a horrible way.
>
> For sure, we cannot fix the Altivec spec. Consider that Altivec does
> not even have an instruction for a value-preserving V4SF->V4SI or
> V4SI->V4SF conversion.
So, is Altivec a de facto standard to be faithfully adhered to by all
compilers? A point of departure?
The C spec for Altivec (not the ISA) is a horrible spec that set a
horrible de facto standard. To some extent, gcc already departed from
Altivec, for example by disallowing the (vector int) (1, 2, 3, 4) syntax
-- notice the parentheses instead of the braces -- because it was
extremely hackish to implement in a Bison parser.
Of course, it is not practically doable, to have vector typecasts
preserve values (FLOAT_EXPR) on SSE and bits (VIEW_CONVERT_EXPR) on
Altivec. The availability of generic vector types, which were
overhauled in order to provide portable vector support even for machines
without SIMD hardware, makes it harder to even propose this...
Paolo
