GCC Vector Extensions

Christian Schoenebeck cuse@users.sourceforge.net
Wed Apr 19 20:05:00 GMT 2006


Es geschah am Wednesday, 19. April 2006 17:20 als Andrew Haley schrieb:
> OK, I got it now.
>
> The full spec is at
>
> http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/co
>m.ibm.vacpp6m.doc/language/ref/clrc03altivec_types.htm

Well, this is a different compiler and the docs are just about this compiler, 
not a regular language specification.

> and the relevant passage is
>
> "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."

The bitstream theory is correct, I just checked this.

Es geschah am Wednesday, 19. April 2006 14:58 als Robert Dewar schrieb:
> Andrew Haley wrote:
> > Converting a vector of floats (via a cast) to a vector of ints of the
> > same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> > converted.  This is different from a cast from scalar float to int,
> > where a conversion is performed.a
>
> Yes, that's the way C is defined
>
> From what I can see of the source, this is deliberate.
>
> I should hope so :-)
> >   But is this behaviour documented anywhere?
> In any book on C, or of course in the C standard.

Uh? Since when are vector types part of the C standard? I hardly believe that, 
since other compilers use a different way to declare vector types for 
example. If I'm wrong, could you point us to the relevant passage in the 
specification?

Es geschah am Wednesday, 19. April 2006 15:41 als Ian Lance Taylor schrieb:
> Converting a vector of floats (via a cast) to a vector of ints of the
> same size uses a VIEW_CONVERT_EXPR, so the data are simply copied, not
> converted.  This is different from a cast from scalar float to int,
> where a conversion is performed.
> In general there is a conflict within gcc between treating vectors as
> unitary types and treating them as collections.  In this case we are
> treating them as unary.  However, I think that by analogy to the way
> we handle arithmetic, and given the existence of instructions like
> cvtdq2ps in real vector processors, I think it would be better to
> handle converstions on an element by element basis.
>
> That is, I think this is a bug.

Exactly, logically it should be treated on element basis by default. I'll dig 
if I can find something about this in the C specs, but I doubt it. ATM I 
assume this to be a wrong implementation of the cast.

Es geschah am Wednesday, 19. April 2006 17:16 als Paolo Bonzini schrieb:
> > 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.

That's an irrational argument to me, defining a high level language based on 
certain low level circumstances of one, single architecture.

>  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.

Yeah, but also consider that old PPCs did not even have an instruction for
int->float conversion. Is that a reason for defining a scalar int->float cast 
as bitstream copy? Certainly not.

CU
Christian



More information about the Gcc-help mailing list