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
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 o
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 b
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 'op
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 'flo
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 - (i>>1);
> 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 - (i>>1);
>> x = *(float*)&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 wou
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-bi
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 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.
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 b
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'
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 s
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 ins
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 instructio
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 "vec
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 my
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 a
"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 mand
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 __at
# 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".
Tha
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 bas
"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
> 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
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 p
"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 prohibi
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
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 i
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 machi
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 intrinsi
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 wri
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 writi
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
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 ac
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.
>>
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
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 y
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. S
> > I'm partly worried about cross-platform compatibility, and what this
> > imples for other SIMD targets.
>
> Yes. Here's a proposed definition:
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 to
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
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 vec
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
tbp wrote:
On 8/23/07, Tim Prince <[EMAIL PROTECTED]> wrote:
Note that icc9 has a strong bias for pentium4, which had no stall
penalty for mistyped fp vectors as for Intel it came with the pentium
M line, so you see a pxor even if generating code for the core2.
# cat autoicc.cc
float foo(cons
59 matches
Mail list logo
