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
