given that we know
that the processor supports bitwise-or on floating point values, using
a instruction different from that for bitwise-or on integer values,
then it is fair to ask why we don't support vector | vector for
floating point vectors.
Because processors may add weird instructions for
Let's assume that the recent change is what we want, i.e., that the
answer to (1) is No, these operations should not be part of the vector
extensions because they are not valid scalar extensions. So, that
means we need to answer (2).
We still have the problem that users now can't write
Paolo Bonzini wrote:
2) selection operations on vectors, kind of (v1 = v2 ? v3 : v4). These
can be written for example like this:
cmpleps xmm1, xmm2 ; xmm1 = xmm1 = xmm2 ? all-ones : 0
andnps xmm4, xmm1 ; xmm4 = xmm1 = xmm2 ? 0 : xmm4
andps xmm1, xmm3 ; xmm1 = xmm1 =
Mark Mitchell wrote:
One option is for the user to use intrinsics. It's been claimed that
results in worse code. There doesn't seem any obvious reason for that,
but, if true, we should try to fix it; we don't want to penalize people
who are using the intrinsics. So, let's assume using
Paolo Bonzini wrote:
I'm not sure that it is *so* useful for a user to have access to it,
except for specialized cases:
As there's other means, it may not be that useful but for sure it's
extremely convenient.
2) selection operations on vectors, kind of (v1 = v2 ? v3 : v4). These
can be
Paolo Bonzini [EMAIL PROTECTED] writes:
1) neg, abs and copysign operations on vectors. These we can make
available via builtins (for - of course you don't need it); we already
support them in many back-ends.
Here is my point of view. People using the vector extensions are
already writing
On Friday 24 August 2007, Ian Lance Taylor wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
1) neg, abs and copysign operations on vectors. These we can make
available via builtins (for - of course you don't need it); we already
support them in many back-ends.
Here is my point of view.
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour, and it
helps programmers and helps existing code. Who does it hurt to permit
this extension? Who does it help to forbid this extension?
Aren't builtins the designated way to
Chris Lattner [EMAIL PROTECTED] writes:
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour, and it
helps programmers and helps existing code. Who does it hurt to permit
this extension? Who does it help to forbid this
Paul Brook wrote:
On Friday 24 August 2007, Ian Lance Taylor wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
1) neg, abs and copysign operations on vectors. These we can make
available via builtins (for - of course you don't need it); we already
support them in many back-ends.
Here is my
On Aug 24, 2007, at 8:37 AM, Ian Lance Taylor wrote:
Chris Lattner [EMAIL PROTECTED] writes:
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour,
and it
helps programmers and helps existing code. Who does it hurt to
permit
On 8/24/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Let a and b be floating-point operands of type F, where F is a
floating-point type. Let N be the number of bytes in F. Then, a | b
is defined as:
Yes that makes sense, not. Since most of the time, you have a mask
and that is what is being
Andrew Pinski wrote:
On 8/24/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Let a and b be floating-point operands of type F, where F is a
floating-point type. Let N be the number of bytes in F. Then, a | b
is defined as:
Yes that makes sense, not.
I'm not following. Are you agreeing or
On 24 August 2007 17:04, Andrew Pinski wrote:
On 8/24/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Let a and b be floating-point operands of type F, where F is a
floating-point type. Let N be the number of bytes in F. Then, a | b
is defined as:
Yes that makes sense, not. Since most of the
I'm partly worried about cross-platform compatibility, and what this
imples for other SIMD targets.
Yes. Here's a proposed definition:
snip
I agree this is the only sane definition.
I probably wasn't clear: My main concern is that if we do support this
extension the internals should be
Paul Brook wrote:
I probably wasn't clear: My main concern is that if we do support this
extension the internals should be implemented and documented in such a way
that target maintainers (i.e. me) can figure out how to make it work on their
favourite target. We should not just quietly
If there is a reason to put in that obstacle--e.g., because we
are implementing a language standard and the language standard forbids
it--then fine. But citing a PowerPC specific standard to forbid code
appropriate for the x86 does not count as a sufficient reason in my
book.
The code I want
On Fri, Aug 24, 2007 at 02:34:27PM -0400, Ross Ridge wrote:
Mark Mitchell
Let's assume that the recent change is what we want, i.e., that the
answer to (1) is No, these operations should not be part of the vector
extensions because they are not valid scalar extensions.
I don't think we
Mark Mitchell
Let's assume that the recent change is what we want, i.e., that the
answer to (1) is No, these operations should not be part of the vector
extensions because they are not valid scalar extensions.
I don't think we should assume that. If we were to we'd also have
to change vector
The IA-32 instruction set does distignuish between integer and
floating point bitiwse operations. In addition to the single-precision
floating-point bitwise instructions that tbp mentioned (ORPS, ANDPS,
ANDNPS and XORPS) there are both distinct double-precision floating-point
bitwise
Why did Intel split up these instructions in the first place, is it
because they wanted to have a seperate vector units in some cases?
I don't know and I don't care that much.
To some extent I agree with Andrew Pinski here. Saying that you need
support in a generic vector extension for
Ross Ridge wrote:
If I were tbp, I'd just code all his vector operatations using intrinsics.
The other responses in this thread have made it clear that GCC's vector
arithemetic operations are really only designed to be used with the Cell
Broadband Engine and other Power PC processors.
Thing is
Andrew Pinski wrote:
Which hardware (remember GCC is a generic compiler)? VMX/Altivec and
SPU actually does not have different instructions for bitwise
and/ior/xor for different vector types (it is all the same
instruction). I have ran into ICEs with even bitwise on vector
float/double on x86
The types defined in this manner can be used with a subset of normal C
operations. Currently, GCC will allow using the following operators on
these types: +, -, *, /, unary minus, ^, |, , ~..
What was missing is when allowed by the base type. E.g. is not
supported.
Paolo
Paolo Bonzini wrote:
To some extent I agree with Andrew Pinski here. Saying that you need
support in a generic vector extension for vector float | vector float
in order to generate ANDPS and not PXOR, is just wrong. That should be
done by the back-end.
I guess i fail to grasp the logic
tbp wrote:
Paolo Bonzini wrote:
To some extent I agree with Andrew Pinski here. Saying that you need
support in a generic vector extension for vector float | vector
float in order to generate ANDPS and not PXOR, is just wrong. That
should be done by the back-end.
I guess i fail to grasp
GCC makes the problem is even worse if only SSE and not SSE 2 instructions
are enabled. Since the integer bitwise instructions are only available
with SSE 2, using casts instead of intrinsics causes GCC to expand the
operation into a long series of instructions.
This was also a bug and a patch
Paolo Bonzini wrote:
Because it's *not* strictly typed. Strict typing means that you accept
the same things accepted for the element type. So it's not a
regression, it's a bug fix.
# cat regressionorbugfix.cc
typedef float v4sf_t __attribute__ ((__vector_size__ (16)));
typedef int v4si_t
# cat regressionorbugfix.cc
typedef float v4sf_t __attribute__ ((__vector_size__ (16)));
typedef int v4si_t __attribute__ ((__vector_size__ (16)));
v4sf_t foo(v4sf_t a, v4sf_t b, v4sf_t c) {
return a + (b | c);
}
v4sf_t bar(v4sf_t a, v4sf_t b, v4sf_t c) {
return a + (v4sf_t) ((v4si_t) b
On 8/23/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
I've added 5 minutes ago an XFAILed test for exactly this code. OTOH, I
have also committed a fix that will avoid producing tons of shuffle and
unpacking instructions when function bar is compiled with -msse but
without -msse2.
Thanks.
I'm
Paolo Bonzini wrote:
I'm curious, does ICC support vector arithmetic like this?
The primary icc/icl use of SSE/SSE2 masking operations, of course, is in
the auto-vectorization of fabs[f] and conditional operations:
sum = 0.f;
i__2 = *n;
for (i__ = 1; i__ = i__2; ++i__)
On 8/23/07, Tim Prince [EMAIL PROTECTED] wrote:
The primary icc/icl use of SSE/SSE2 masking operations, of course, is in
the auto-vectorization of fabs[f] and conditional operations:
sum = 0.f;
i__2 = *n;
for (i__ = 1; i__ = i__2; ++i__)
if (a[i__] 0.f)
Paolo Bonzini [EMAIL PROTECTED] writes:
The types defined in this manner can be used with a subset of
normal C operations. Currently, GCC will allow using the following
operators on these types: +, -, *, /, unary minus, ^, |, , ~..
What was missing is when allowed by the base type. E.g.
The types defined in this manner can be used with a subset of
normal C operations. Currently, GCC will allow using the following
operators on these types: +, -, *, /, unary minus, ^, |, , ~..
What was missing is when allowed by the base type. E.g. is not
supported.
I think we should revert
There seem to be solid reasons to permit this, and no very strong ones
to prohibit it. We can consider it to be a GNU extension for vectors.
Vectors are of course themselves an extension already.
How are you suggesting it be implemented?
Will the front/middle-end convert it to (vNsf)((vNsi)a
Hi,
On Thu, 23 Aug 2007, Paul Brook wrote:
There seem to be solid reasons to permit this, and no very strong ones
to prohibit it. We can consider it to be a GNU extension for vectors.
Vectors are of course themselves an extension already.
How are you suggesting it be implemented?
On Thu, 23 Aug 2007, Ian Lance Taylor wrote:
I think we should revert the patch, and continue permitting the
bitwise operations on vector float.
There seem to be solid reasons to permit this, and no very strong ones
to prohibit it. We can consider it to be a GNU extension for vectors.
On 8/23/07, Joseph S. Myers [EMAIL PROTECTED] wrote:
On Thu, 23 Aug 2007, Ian Lance Taylor wrote:
I think we should revert the patch, and continue permitting the
bitwise operations on vector float.
There seem to be solid reasons to permit this, and no very strong ones
to prohibit it.
Joseph S. Myers [EMAIL PROTECTED] writes:
| On Thu, 23 Aug 2007, Ian Lance Taylor wrote:
|
| I think we should revert the patch, and continue permitting the
| bitwise operations on vector float.
|
| There seem to be solid reasons to permit this, and no very strong ones
| to prohibit it.
On 8/23/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 8/23/07, Joseph S. Myers [EMAIL PROTECTED] wrote:
We decided long ago that the extension would be based on what's permitted
by C++ valarray rather than by a particular CPU's vector intrinsics. So
unless C++ valarray allows this
Paolo Bonzini wrote:
Why did Intel split up these instructions in the first place, is it
because they wanted to have a seperate vector units in some cases?
I don't know and I don't care that much.
To some extent I agree with Andrew Pinski here. Saying that you need
support in a generic
Apparently enough for a small vendor like Intel to propose such things
as orps, andps, andnps, and xorps.
I think you're running too far with your sarcasm. SSE's instructions do
not go so far as to specify integer vs. floating point. To me, ps
means 32-bit SIMD, independent of integerness.
On 22 August 2007 06:10, Ian Lance Taylor wrote:
tbp [EMAIL PROTECTED] writes:
vecop.cc:4: error: invalid operands of types 'float __vector__' and
'float __vector__' to binary 'operator|'
vecop.cc:5: error: invalid operands of types 'float __vector__' and
'float __vector__' to binary
On 8/21/07, tbp [EMAIL PROTECTED] wrote:
# /usr/local/gcc-4.3-svn.old6/bin/g++ vecop.cc
vecop.cc: In function 'T foo() [with T = float __vector__]':
vecop.cc:13: instantiated from here
vecop.cc:4: error: invalid operands of types 'float __vector__' and
'float __vector__' to binary
On 22 August 2007 11:13, Andrew Pinski wrote:
On 8/21/07, tbp [EMAIL PROTECTED] wrote:
# /usr/local/gcc-4.3-svn.old6/bin/g++ vecop.cc
vecop.cc: In function 'T foo() [with T = float __vector__]':
vecop.cc:13: instantiated from here
vecop.cc:4: error: invalid operands of types 'float
On 8/22/07, Dave Korn [EMAIL PROTECTED] wrote:
float InvSqrt (float x){
float xhalf = 0.5f*x;
int i = *(int*)x;
You are violating C/C++ aliasing rules here anyways.
i = 0x5f3759df - (i1);
x = *(float*)i;
Likewise.
So I guess you like to depend on undefined code :).
--
On 22 August 2007 11:40, Andrew Pinski wrote:
On 8/22/07, Dave Korn [EMAIL PROTECTED] wrote:
float InvSqrt (float x){
float xhalf = 0.5f*x;
int i = *(int*)x;
You are violating C/C++ aliasing rules here anyways.
i = 0x5f3759df - (i1);
x = *(float*)i;
Likewise.
So I
On Wed, Aug 22, 2007 at 11:47:52AM +0100, Dave Korn wrote:
Well, I like to think that I could cast the address to unsigned char*,
memcpy a bunch of them to the address of an int, then dereference the int and
the compiler would realise it was a no-op and optimise it away, but I doubt
On 22 August 2007 14:06, Rask Ingemann Lambertsen wrote:
On Wed, Aug 22, 2007 at 11:47:52AM +0100, Dave Korn wrote:
Well, I like to think that I could cast the address to unsigned char*,
memcpy a bunch of them to the address of an int, then dereference the int and
the compiler would
tbp writes:
Apparently enough for a small vendor like Intel to propose such things
as orps, andps, andnps, and xorps.
Paolo Bonzini writes:
I think you're running too far with your sarcasm. SSE's instructions
do not go so far as to specify integer vs. floating point. To me, ps
means 32-bit SIMD,
On 8/22/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
I think you're running too far with your sarcasm. SSE's instructions do
not go so far as to specify integer vs. floating point. To me, ps
means 32-bit SIMD, independent of integerness.
Excuse me if i'm amazed being replied bitwise ops on
On 8/22/07, tbp [EMAIL PROTECTED] wrote:
On 8/22/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
I think you're running too far with your sarcasm. SSE's instructions do
not go so far as to specify integer vs. floating point. To me, ps
means 32-bit SIMD, independent of integerness.
Excuse me if
On 8/22/07, Andrew Pinski [EMAIL PROTECTED] wrote:
Which hardware (remember GCC is a generic compiler)? VMX/Altivec and
SPU actually does not have different instructions for bitwise
and/ior/xor for different vector types (it is all the same
instruction). I have ran into ICEs with even
Ross Ridge writes:
tbp is correct. Using casts gets you the integer bitwise instrucitons,
not the single-precision bitwise instructions that are more optimal for
flipping bits in single-precision vectors. If you want GCC to generate
better code using single-precision bitwise instructions you're
On 8/22/07, Ross Ridge [EMAIL PROTECTED] wrote:
GCC makes the problem is even worse if only SSE and not SSE 2 instructions
are enabled. Since the integer bitwise instructions are only available
with SSE 2, using casts instead of intrinsics causes GCC to expand the
operation into a long series
Ross Ridge [EMAIL PROTECTED] wrote:
GCC makes the problem is even worse if only SSE and not SSE 2 instructions
are enabled. Since the integer bitwise instructions are only available
with SSE 2, using casts instead of intrinsics causes GCC to expand the
operation into a long series of
Hello,
# cat vecop.cc
templatetypename T T foo() {
T
a = { 0, 1, 2, 3 }, b = { 4, 5, 6, 7 },
c = a | b,
d = c b,
e = d ^ b;
return e;
}
int main() {
typedef float v4sf_t __attribute__ ((__vector_size__
tbp [EMAIL PROTECTED] writes:
vecop.cc:4: error: invalid operands of types 'float __vector__' and
'float __vector__' to binary 'operator|'
vecop.cc:5: error: invalid operands of types 'float __vector__' and
'float __vector__' to binary 'operator'
vecop.cc:6: error: invalid operands of types
Ian Lance Taylor wrote:
What does it mean to do a bitwise-or of a floating point value?
Apparently enough for a small vendor like Intel to propose such things
as orps, andps, andnps, and xorps.
So, that's what i feared... it was intentional. And now i guess the only
sanctioned access to those
59 matches
Mail list logo
