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.
