Conversions of ext_vector types

As a C programmer, I find the behaviour of ext_vector conversions
surprising.

typedef float float4 __attribute__((ext_vector_type(4)));
typedef int int4 __attribute__((ext_vector_type(4)));
float4 f(float4 a, int4 b)
{
     return a + b;
}

define <4 x float> @f(<4 x float> %a, <4 x i32> %b) nounwind uwtable readnone {
entry:
   %0 = bitcast <4 x i32> %b to <4 x float>
   %add = fadd <4 x float> %0, %a
   ret <4 x float> %add
}

I've looked, but not found the story behind this. Would there be
objections to having conversions, like other ext_vector operations,
perform the corresponding scalar operation elementwise instead?

I am no an cfe vector expr developer, so I also don't know the story behind this, but I guess this is a bug of cfe.

To add an information a bit, the code handles float4 + int4 arithmetic with conversion-free casting, whereas OpenCL keenel and gcc vector extension(and possibly AltiVec extension) does not allow float4 + int4 expression.

Also note, arithmetic operations and type casting is not C compatible for vector variables(see OpenCL spec for example)

Wei Pan pointed me to <http://gcc.gnu.org/ml/gcc/2006-10/msg00242.html>,
which explains that the surprising silent bitcast originates with the
AltiVec programming model.

Excluding the LangOptions.AltiVec case, and any others with special
rules, would there be objections to having ext_vector conversions
perform the 'natural' elementwise conversion?