* Gcc vector extensions
@ 2011-02-28 23:37 Hari Sandanagobalane
2011-02-28 23:55 ` Ian Lance Taylor
0 siblings, 1 reply; 16+ messages in thread
From: Hari Sandanagobalane @ 2011-02-28 23:37 UTC (permalink / raw)
To: gcc-help
Hello,
Picochip processor has a vector unit that supports operations such as
ADD imm,vsrc,vdest.
where you can add a scalar value to a vector register. This is
equivalent to adding every element of the vector register with the
scalar value.
GCC vector extensions allow for a scalar to be used for shift
operations. This example from documentation says
typedef int v4si __attribute__ ((vector_size (16)));
v4si a, b;
b = a >> 1; /* b = a >> {1,1,1,1}; */
Is it possible to support
b = a + 1 /* b = a + {1,1,1,1} */
Or, is there any other way to represent this operation?
Thanks for your help.
Cheers
Hari
Note: I am not sure whether this is the right mailing list for this
discussion.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Gcc vector extensions
2011-02-28 23:37 Gcc vector extensions Hari Sandanagobalane
@ 2011-02-28 23:55 ` Ian Lance Taylor
0 siblings, 0 replies; 16+ messages in thread
From: Ian Lance Taylor @ 2011-02-28 23:55 UTC (permalink / raw)
To: Hari Sandanagobalane; +Cc: gcc-help
Hari Sandanagobalane <hariharans@picochip.com> writes:
> Picochip processor has a vector unit that supports operations such as
>
> ADD imm,vsrc,vdest.
>
> where you can add a scalar value to a vector register. This is
> equivalent to adding every element of the vector register with the
> scalar value.
>
> GCC vector extensions allow for a scalar to be used for shift
> operations. This example from documentation says
>
> typedef int v4si __attribute__ ((vector_size (16)));
>
> v4si a, b;
>
> b = a >> 1; /* b = a >> {1,1,1,1}; */
>
> Is it possible to support
>
> b = a + 1 /* b = a + {1,1,1,1} */
>
> Or, is there any other way to represent this operation?
That is not currently supported as you wrote it. It would have to be
done using a builtin function.
Ian
^ permalink raw reply [flat|nested] 16+ messages in thread
* GCC vector extensions.
@ 2010-11-04 16:14 Hariharan Sandanagobalane
2010-11-04 18:59 ` Ian Lance Taylor
0 siblings, 1 reply; 16+ messages in thread
From: Hariharan Sandanagobalane @ 2010-11-04 16:14 UTC (permalink / raw)
To: gcc-help
Hello,
I have a feeling the website is wrong. If you went to
http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html, it claims
"In C vectors can be subscripted as if the vector were an array with the
same number of elements and base type. Out of bound accesses invoke
undefined behavior at runtime. Warnings for out of bound accesses for
vector subscription can be enabled with -Warray-bounds. "
I went through the gcc source code and the extend.texi does not have
this statement anymore. Why is that not reflected on the website?
When i tried that in a simple example.
#define vector __attribute__((vector_size(16) ))
static inline vector int vectadd(vector int t1, vector int t2)
{
return t1 + t2;
}
vector int a = {0, 1, 0, 1, 0, 0, 0, 0};
vector int b = {0, 0, 1, 1, 0, 0, 0, 0};
vector int c = {0, 1, 1, 0, 0, 0, 0, 0};
int main(void)
{
vector int a0;
a0 = vectadd(a, b);
if (a0[2] != 1)
__builtin_abort ();
return 0;
}
I get a compiler error "error: subscripted value is neither array nor
pointer".
Cheers
Hari
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC vector extensions.
2010-11-04 16:14 GCC " Hariharan Sandanagobalane
@ 2010-11-04 18:59 ` Ian Lance Taylor
0 siblings, 0 replies; 16+ messages in thread
From: Ian Lance Taylor @ 2010-11-04 18:59 UTC (permalink / raw)
To: Hariharan Sandanagobalane; +Cc: gcc-help
Hariharan Sandanagobalane <hariharans@picochip.com> writes:
> I have a feeling the website is wrong. If you went to
> http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html, it claims
>
> "In C vectors can be subscripted as if the vector were an array with
> the same number of elements and base type. Out of bound accesses
> invoke undefined behavior at runtime. Warnings for out of bound
> accesses for vector subscription can be enabled with -Warray-bounds. "
>
> I went through the gcc source code and the extend.texi does not have
> this statement anymore. Why is that not reflected on the website?
I see that statement in the current source code. I expect that you are
looking at an older release.
Vector subscripting was added quite recently and is not yet in any gcc
release. When you read http://gcc.gnu.org/onlinedocs/gcc/ you are
reading the docs for the current development release. If you look at
http://gcc.gnu.org/onlinedocs/ you can select the documentation
appropriate to the release you are using. If you started from that
page, you are selecting the manual which follows a note "Some
information may not be applicable to any existing release."
Ian
^ permalink raw reply [flat|nested] 16+ messages in thread
* GCC Vector Extensions
@ 2006-04-07 19:03 Christian Schoenebeck
2006-04-07 20:16 ` Greg Buchholz
0 siblings, 1 reply; 16+ messages in thread
From: Christian Schoenebeck @ 2006-04-07 19:03 UTC (permalink / raw)
To: gcc-help; +Cc: linuxsampler-devel
Hi!
I just read the GCC Vector Extensions doc [1] and have a few questions.
a) The last code block in that doc [1] uses "builtin" functions? Why should
somebody use those builtin functions when the normal C operations on the new
vector extension types do the same?
b) We wondered [2] what the currently best way is to access single elements of
one vector. Currently the only solution we saw is to use a union trick like:
typedef struct {
float _1;
float _2;
float _3;
float _4;
} quad_samples;
typedef float v4sf __attribute__ ((vector_size (16)));
typedef union {
quad_samples s;
v4sf v;
} quad_sample_t;
Is there a better way to access single elements of a vector?
c) What I'm missing a lot (especially for digital signal processing) are (bit)
shifting operations on the new vector types. Are those planned or already in
work?
[1] http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Vector-Extensions.html#Vector-Extensions
[2] https://bugs.linuxsampler.org/cgi-bin/show_bug.cgi?id=25
CU
Christian
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-07 19:03 GCC Vector Extensions Christian Schoenebeck
@ 2006-04-07 20:16 ` Greg Buchholz
2006-04-15 0:58 ` Christian Schoenebeck
0 siblings, 1 reply; 16+ messages in thread
From: Greg Buchholz @ 2006-04-07 20:16 UTC (permalink / raw)
To: gcc-help
Christian Schoenebeck wrote:
> b) We wondered [2] what the currently best way is to access single elements of
> one vector. Currently the only solution we saw is to use a union trick
/* I don't know if this qualifies as good, but here's some things
I've used before */
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
typedef float v4sf __attribute__ ((vector_size (16)));
int main()
{
v4sf a,b,c;
float *z;
((float *)&a)[0] = 1.0;
((float *)&a)[1] = 2.0;
((float *)&a)[2] = 3.0;
((float *)&a)[3] = 4.0;
memcpy((float *)&b,(float[]){0.5,0.6,0.7,0.8},4*sizeof(float));
c = a + b;
z = (float *)&c;
printf("%f, %f, %f, %f\n", *z, *(z+1), z[2], z[3]);
return 0;
}
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-07 20:16 ` Greg Buchholz
@ 2006-04-15 0:58 ` Christian Schoenebeck
2006-04-18 10:04 ` Andrew Haley
0 siblings, 1 reply; 16+ messages in thread
From: Christian Schoenebeck @ 2006-04-15 0:58 UTC (permalink / raw)
To: gcc-help
Es geschah am Friday, 7. April 2006 22:17 als Greg Buchholz schrieb:
> Christian Schoenebeck wrote:
> > b) We wondered [2] what the currently best way is to access single
> > elements of one vector. Currently the only solution we saw is to use a
> > union trick
>
> /* I don't know if this qualifies as good, but here's some things
> I've used before */
Oh, it officially qualified as good! We just made some benchmarks [1] to
compare our old union trick vs. your straight forward type casts and your
solutions were always faster, often even quite a lot. So as we thought, gcc
doesn't like that union thing very much.
Thanks!
CU
Christian
[1] http://sourceforge.net/mailarchive/forum.php?thread_id=10134400&forum_id=12792
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-15 0:58 ` Christian Schoenebeck
@ 2006-04-18 10:04 ` Andrew Haley
2006-04-18 23:38 ` Christian Schoenebeck
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Haley @ 2006-04-18 10:04 UTC (permalink / raw)
To: Christian Schoenebeck; +Cc: gcc-help
Christian Schoenebeck writes:
> Es geschah am Friday, 7. April 2006 22:17 als Greg Buchholz schrieb:
> > Christian Schoenebeck wrote:
> > > b) We wondered [2] what the currently best way is to access single
> > > elements of one vector. Currently the only solution we saw is to use a
> > > union trick
> >
> > /* I don't know if this qualifies as good, but here's some things
> > I've used before */
>
> Oh, it officially qualified as good! We just made some benchmarks
> [1] to compare our old union trick vs. your straight forward type
> casts and your solutions were always faster, often even quite a
> lot. So as we thought, gcc doesn't like that union thing very much.
It's not legal C, though. The _mm_load, _mm_set, and _mm_store
operations are provided to do the conversions.
Andrew.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-18 10:04 ` Andrew Haley
@ 2006-04-18 23:38 ` Christian Schoenebeck
2006-04-19 8:30 ` Andrew Haley
0 siblings, 1 reply; 16+ messages in thread
From: Christian Schoenebeck @ 2006-04-18 23:38 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc-help, linuxsampler-devel
Es geschah am Tuesday, 18. April 2006 12:04 als Andrew Haley schrieb:
> Christian Schoenebeck writes:
> > Es geschah am Friday, 7. April 2006 22:17 als Greg Buchholz schrieb:
> > > Christian Schoenebeck wrote:
> > > > b) We wondered [2] what the currently best way is to access single
> > > > elements of one vector. Currently the only solution we saw is to use
> > > > a union trick
> > >
> > > /* I don't know if this qualifies as good, but here's some things
> > > I've used before */
> >
> > Oh, it officially qualified as good! We just made some benchmarks
> > [1] to compare our old union trick vs. your straight forward type
> > casts and your solutions were always faster, often even quite a
> > lot. So as we thought, gcc doesn't like that union thing very much.
>
> It's not legal C, though. The _mm_load, _mm_set, and _mm_store
> operations are provided to do the conversions.
Well, those intrinsics would make it hardware dependent though. I thought the
reason for introducing the vector extension was to avoid this. Anyway, I don't
mind if this is legal C or not until it works^TM.
Unfortunately we found a case [1] which did not work at all: a type cast from
float vector to integer vector, like:
typedef float v4sf __attribute__ ((vector_size(16),aligned(16)));
typedef int v4i __attribute__ ((vector_size(sizeof(int)*4)));
int main() {
const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
const v4i vRes = (v4i) v;
}
The resulting integer vector vRes would simply contain crap.
Is this a bug, not implemented yet or even intentional?
CU
Christian
[1] http://sourceforge.net/mailarchive/forum.php?thread_id=10191980&forum_id=12792
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-18 23:38 ` Christian Schoenebeck
@ 2006-04-19 8:30 ` Andrew Haley
2006-04-19 12:19 ` Christian Schoenebeck
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Haley @ 2006-04-19 8:30 UTC (permalink / raw)
To: Christian Schoenebeck; +Cc: gcc-help, linuxsampler-devel
Christian Schoenebeck writes:
> Es geschah am Tuesday, 18. April 2006 12:04 als Andrew Haley schrieb:
> > Christian Schoenebeck writes:
> > > Es geschah am Friday, 7. April 2006 22:17 als Greg Buchholz schrieb:
> > > > Christian Schoenebeck wrote:
> > > > > b) We wondered [2] what the currently best way is to access single
> > > > > elements of one vector. Currently the only solution we saw is to use
> > > > > a union trick
> > > >
> > > > /* I don't know if this qualifies as good, but here's some things
> > > > I've used before */
> > >
> > > Oh, it officially qualified as good! We just made some benchmarks
> > > [1] to compare our old union trick vs. your straight forward type
> > > casts and your solutions were always faster, often even quite a
> > > lot. So as we thought, gcc doesn't like that union thing very much.
> >
> > It's not legal C, though. The _mm_load, _mm_set, and _mm_store
> > operations are provided to do the conversions.
>
> Well, those intrinsics would make it hardware dependent though. I
> thought the reason for introducing the vector extension was to
> avoid this. Anyway, I don't mind if this is legal C or not until it
> works^TM.
>
> Unfortunately we found a case [1] which did not work at all: a type cast from
> float vector to integer vector, like:
>
> typedef float v4sf __attribute__ ((vector_size(16),aligned(16)));
> typedef int v4i __attribute__ ((vector_size(sizeof(int)*4)));
>
> int main() {
> const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
> const v4i vRes = (v4i) v;
> }
>
> The resulting integer vector vRes would simply contain crap.
> Is this a bug, not implemented yet or even intentional?
I don't know, because there's not enough information here. Can you
produce a runnable test case?
Andrew.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-19 8:30 ` Andrew Haley
@ 2006-04-19 12:19 ` Christian Schoenebeck
2006-04-19 13:13 ` John Love-Jensen
2006-04-19 14:03 ` Andrew Haley
0 siblings, 2 replies; 16+ messages in thread
From: Christian Schoenebeck @ 2006-04-19 12:19 UTC (permalink / raw)
To: gcc-help; +Cc: Andrew Haley, linuxsampler-devel
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
Es geschah am Wednesday, 19. April 2006 10:30 als Andrew Haley schrieb:
> > Unfortunately we found a case [1] which did not work at all: a type cast
> > from float vector to integer vector, like:
> >
> > typedef float v4sf __attribute__ ((vector_size(16),aligned(16)));
> > typedef int v4i __attribute__ ((vector_size(sizeof(int)*4)));
> >
> > int main() {
> > const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
> > const v4i vRes = (v4i) v;
> > }
> >
> > The resulting integer vector vRes would simply contain crap.
> > Is this a bug, not implemented yet or even intentional?
>
> I don't know, because there's not enough information here. Can you
> produce a runnable test case?
Ok, attached you find one with output. When you run it, it should actually
show this:
v4sf v = { 1.200000, 2.200000, 3.300000, 4.400000 }
v4i vRes = { 1, 2, 3, 4 }
but instead I get this:
v4sf v = { 1.200000, 2.200000, 3.300000, 4.400000 }
v4i vRes = { 1067030938, 1074580685, 1079194419, 1082969293 }
I can hardly believe this is intentional, is it?
CU
Christian
[-- Attachment #2: foo.cpp --]
[-- Type: text/x-c++src, Size: 470 bytes --]
#include <stdio.h>
typedef float v4sf __attribute__ ((vector_size(16),aligned(16)));
typedef int v4i __attribute__ ((vector_size(sizeof(int)*4)));
int main() {
const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
printf("v4sf v = { %f, %f, %f, %f }\n", ((float*)&v)[0],((float*)&v)[1],((float*)&v)[2],((float*)&v)[3]);
const v4i vRes = (v4i) v;
printf("v4i vRes = { %d, %d, %d, %d }\n", ((int*)&vRes)[0],((int*)&vRes)[1],((int*)&vRes)[2],((int*)&vRes)[3]);
}
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-19 12:19 ` Christian Schoenebeck
@ 2006-04-19 13:13 ` John Love-Jensen
2006-04-19 14:03 ` Andrew Haley
1 sibling, 0 replies; 16+ messages in thread
From: John Love-Jensen @ 2006-04-19 13:13 UTC (permalink / raw)
To: Christian Schoenebeck, MSX to GCC; +Cc: Andrew Haley, linuxsampler-devel
Hi Christian,
I believe the...
const v4i vRes = (v4i) v;
...will do a memcpy, not a float to int conversion.
If you change it to...
const v4i vRes = v;
... you get error: cannot convert 'const float __vector__' to 'const int
__vector__' in initialization
I think your big hammer cast is hiding the problem. Your %d output is the
int32 values of the bit patterns of the float32 values.
HTH,
--Eljay
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-19 12:19 ` Christian Schoenebeck
2006-04-19 13:13 ` John Love-Jensen
@ 2006-04-19 14:03 ` Andrew Haley
2006-04-19 15:20 ` Andrew Haley
1 sibling, 1 reply; 16+ messages in thread
From: Andrew Haley @ 2006-04-19 14:03 UTC (permalink / raw)
To: Christian Schoenebeck; +Cc: gcc-help, linuxsampler-devel
Christian Schoenebeck writes:
> Es geschah am Wednesday, 19. April 2006 10:30 als Andrew Haley schrieb:
> > > Unfortunately we found a case [1] which did not work at all: a type cast
> > > from float vector to integer vector, like:
> > >
> > > typedef float v4sf __attribute__ ((vector_size(16),aligned(16)));
> > > typedef int v4i __attribute__ ((vector_size(sizeof(int)*4)));
> > >
> > > int main() {
> > > const v4sf v = { 1.2f ,2.2f ,3.3f, 4.4f };
> > > const v4i vRes = (v4i) v;
> > > }
> > >
> > > The resulting integer vector vRes would simply contain crap.
> > > Is this a bug, not implemented yet or even intentional?
> >
> > I don't know, because there's not enough information here. Can you
> > produce a runnable test case?
>
> Ok, attached you find one with output. When you run it, it should actually
> show this:
>
> v4sf v = { 1.200000, 2.200000, 3.300000, 4.400000 }
> v4i vRes = { 1, 2, 3, 4 }
>
> but instead I get this:
>
> v4sf v = { 1.200000, 2.200000, 3.300000, 4.400000 }
> v4i vRes = { 1067030938, 1074580685, 1079194419, 1082969293 }
>
> I can hardly believe this is intentional, is it?
I've started a conversation on the gcc discuss list, and we think it's
probably a bug. There's a thread at
http://gcc.gnu.org/ml/gcc/2006-04/msg00349.html.
Andrew.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-19 14:03 ` Andrew Haley
@ 2006-04-19 15:20 ` Andrew Haley
2006-04-19 20:05 ` Christian Schoenebeck
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Haley @ 2006-04-19 15:20 UTC (permalink / raw)
To: Christian Schoenebeck, gcc-help, linuxsampler-devel
OK, I got it now.
The full spec is at
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc03altivec_types.htm
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."
Andrew.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-19 15:20 ` Andrew Haley
@ 2006-04-19 20:05 ` Christian Schoenebeck
2006-04-19 20:25 ` Andrew Haley
0 siblings, 1 reply; 16+ messages in thread
From: Christian Schoenebeck @ 2006-04-19 20:05 UTC (permalink / raw)
To: gcc-help
Cc: Andrew Haley, linuxsampler-devel, Robert Dewar, Ian Lance Taylor,
Paolo Bonzini
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: GCC Vector Extensions
2006-04-19 20:05 ` Christian Schoenebeck
@ 2006-04-19 20:25 ` Andrew Haley
0 siblings, 0 replies; 16+ messages in thread
From: Andrew Haley @ 2006-04-19 20:25 UTC (permalink / raw)
To: Christian Schoenebeck; +Cc: gcc-help
Christian Schoenebeck writes:
> 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=/com.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.
Sure, but it's the base we used for gcc, and it's what current users
expect.
> 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.
Too late: it's the specification. See
"2.4.6 Type Casting
"... None of the casts performs a conversion; the bit pattern of the
result is the same as the bit pattern of the argument that is cast."
The full spec is at http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E/$file/SPU_language_extensions_2.1.pdf
Now, you might think that we need a different specification, and lots
of people would agree with you! But it's not a bug in the gcc
implementation.
Andrew.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-02-28 23:37 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-28 23:37 Gcc vector extensions Hari Sandanagobalane
2011-02-28 23:55 ` Ian Lance Taylor
-- strict thread matches above, loose matches on Subject: below --
2010-11-04 16:14 GCC " Hariharan Sandanagobalane
2010-11-04 18:59 ` Ian Lance Taylor
2006-04-07 19:03 GCC Vector Extensions Christian Schoenebeck
2006-04-07 20:16 ` Greg Buchholz
2006-04-15 0:58 ` Christian Schoenebeck
2006-04-18 10:04 ` Andrew Haley
2006-04-18 23:38 ` Christian Schoenebeck
2006-04-19 8:30 ` Andrew Haley
2006-04-19 12:19 ` Christian Schoenebeck
2006-04-19 13:13 ` John Love-Jensen
2006-04-19 14:03 ` Andrew Haley
2006-04-19 15:20 ` Andrew Haley
2006-04-19 20:05 ` Christian Schoenebeck
2006-04-19 20:25 ` Andrew Haley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).