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 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.
Rather than accusing Intel of bad ISA design and the GCC maintainers of Altivec prejudice, let's just figure out what to do. We all agree that: (1) On Intel CPUs, it's more efficient to use the floating-point bitwise instructions (2) In C, you can't do a bitwise-or on two floating-point types So, we have two questions: (1) Should GCC's vector extensions permit floating-point bitwise operations? (2) If not, how can a user can get efficient code? 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). 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 intrinsics is just as efficient, either because it already is, or because we make it so. We still have the problem that users now can't write machine-independent code to do this operation. Assuming the operations are useful for something (and, if it weren't, why would Intel want to have instructions for it, and why would tbp want to use it?), it seems unfortunate to restrict the extension in this way. We could always support the scalar form too, if we want to maintain consistency between the scalar and vector forms. Presumably, the reason this isn't standard C or C++ is because the standards don't specify a floating-point format. At most, they could have made the behavior implementation-defined. But, if nobody thought it was a useful operation, they probably didn't see any point. What are these operation used for? Can someone give an example of a kernel than benefits from this kind of thing? Assuming there's a plausible use, my suggestion is that we just undo the patch that turned off this functionality. If it doesn't well on some systems, and we don't have any volunteers to write a fully generic (e.g., move float operands to integer registers, bitwise operation, move the result back) then we could always issue a sorry. Users may then have to use #ifdefs on some platforms, but that's no worse than using intrinsics. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
