Re: recent troubles with float vectors & bitwise ops

[Mark Mitchell <mark at codesourcery dot com>]

Paul Brook wrote:
> On Friday 24 August 2007, Ian Lance Taylor wrote:
>> Paolo Bonzini <paolo.bonzini@lu.unisi.ch> 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 inherently machine specific code, and they are
>> (ideally) familiar with the instruction set of their processor.
> 
> By the same argument, If you're already writing machine specific code then 
> there shouldn't be a problem using machine specific intrinsics. I admit I've 
> never been convinced that the generic vector support was sufficient to write 
> useful code without resorting to machine specific intrinsics.

Our VSIPL++ team is using it for some things.  My guess is that it's
probably not sufficient for all things, but probably is sufficient for
many things.  Also, I expect some users get (say) a 4x speedup over C
code easily by using the vector extension, and could get an 8x speedup
by using intrinsics, but with a lot more work.  So, the vector
extensions give them a sweet spot on the performance/effort/portability
curve.

> I'm partly worried about cross-platform compatibility, and what this imples 
> for other SIMD targets.

Yes.  Here's a proposed definition:

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:

  ({ union fi { F f; char bytes[N]; };
     union fi au;
     union fi bu;
     au.f = a;
     bu.f = b;
     for (i = 0; i < N; ++i)
       au.bytes[i] |= bu.bytes[i];
     au.f; })

If the resulting floating-point value is denormal, NaN, etc., whether or
not exceptions are raised is unspecified.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713