Re: Even stricter implicit conversions between vectors

[Ian Ollmann <iano at apple dot com>]

Assuming I understand the proposal properly, this sounds to me like  
it amounts reversing the change  we experienced in the Apple GCC from  
3.3 -> 4.0.  Type checking became a lot more lax for us in 4.0.

We use AltiVec very heavily. From experience in cases when our 4.0  
code had to be back ported to also compile on 3.3 we found that code  
written for 4.0 frequently will fail to compile on 3.3 due to more  
rigorous type checking.

I expect that if you strengthen the type checking here, you will, as  
Mike Stump says, break a lot of code.  The fix is typically trivial,  
but does require someone comfortable with AltiVec, and probably in  
certain cases substantial additional testing to make sure nothing  
broke. (This is typically more of an engineering requirement than a  
practical necessity, since these things are usually in practice  
noops.)  In my own case, I'm expecting that this would set me back no  
more than a week or two as I go through and fix up all of the work  
I've done since the GCC 3.3->4.0 transition. That isn't a big deal  
for me.

The real problem will be for those users who have contracted out with  
a consultant to do optimization. Typically, these people will need to  
either bring the consultant back in  or to be cynical, more likely  
just disable the vector code and use the fallback scalar path  
instead. Vectorization unfortunately appears to be something of a  
specialized field. It is not something that most programmers are  
comfortable with. Consultant written vector code is rather common.

In my opinion, either way is fine. Since the commonly used part* of  
the AltiVec operator set makes heavy use of operator/function  
overloading, stronger type checking seems like a good idea to me in  
general.

Ian

*Stronger typechecking for something like vec_vaddubm() is, however,  
in my opinion more debatable since it completely clear exactly what  
the programmer meant.