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 casts to work like scalar casts and actually convert
the values. (Or like valarray, disallow them completely.) That would
force a solution like Paolo Bonzini's to use unions instead of casts,
making it even more cumbersome.
If you look at what these bitwise operations are doing, they're taking
a floating point vector and applying an operation (eg. negation) to
certain members of the vector of according to a (normally) constant mask.
They're really unaray floating-point vector operations. I don't think
it's unreasonable to want to express these operations using floating-point
vector types directly. Using vector casts that behave differently than
scalar casts has a lot more potential to generate confusion than allowing
bitwise operations on vector floats does.
As I see it, there's two ways you can express these kinds operations
without using casts that are both cumbersome and misleading. The easy
way would be to just revert the change, and allow bitwise operations on
vector floats. This is essentially an "old-school" programmer-knows-best
solution where the compiler provides operators that represent the sort
of operations generally supported by CPUs. Even on Altivec these bitwise
operations on vector floats are meaningful and useful.
The other way is to provide a complete set operations that would
make using the bitwise operators pretty much unnecessary, like it is
with scalar floats. For example, you can express masked negation by
multiplying with a constant vector of -1.0 and 1.0 elements. It shouldn't
be too hard for GCC to optimize this into an appropriate bitwise
instruction for the target. For other operations the solution isn't
as nice. You could implement a set of builtin functions easily enough,
but it wouldn't be much better than using target specific intrinsics.
Chances are though that operatations are going to be missed. For example,
I doubt anyone unfamiliar with 3D programming would've seen the need
for only negating part of a vector.
(A more concise way to eliminate the need for the bitwise operations on
vector floats would be to implement either the "swizzles" used in 3D
shaders or array indexing on vectors. It would require a lot of work
to implement properly, so I don't see it happening.)
Ross Ridge
