[cfe-dev] Matrix Support in Clang

[John McCall via cfe-dev]

On 3 Apr 2020, at 14:17, Florian Hahn wrote:

> > On Apr 2, 2020, at 21:49, John McCall <rjmccall at apple.com> wrote:
>> On 2 Apr 2020, at 16:17, Florian Hahn wrote:
>>
>>>> On Apr 2, 2020, at 17:32, John McCall <rjmccall at apple.com> wrote:
>>>>
>>>> On 1 Apr 2020, at 13:15, Florian Hahn wrote:
>>>> I agree that ideally we would not allow mis-matched binary 
>>>> operations to avoid surprises. It looks like the existing vector 
>>>> type does not perform implicit conversion for binary operations 
>>>> with 2 vector operands (unless the there is a type mis-match and 
>>>> the data size matches, then the LHS type is chosen). For binary ops 
>>>> with vector and scalar operands, the scalar operand is converted to 
>>>> the vector element type. So short4 + short4 -> short4, short4 + int 
>>>> -> short4, short4 + int4 -> invalid.
>>>>
>>>> Given that precedence, I think we should opt for not providing 
>>>> conversions for binary operators with two matrix operands. For the 
>>>> matrix and scalar versions, we could convert to the element type 
>>>> automatically for convenience. But at that point, the gain is 
>>>> probably quite small and it would be simpler to don’t do 
>>>> conversions in any case. Does that sound reasonable?
>>>>
>>>> I think converting scalars is a necessary convenience in C given 
>>>> that e.g. literals are normally of type int, but yes, I think 
>>>> it’s fine to not implicitly convert matrices as long as you have 
>>>> a way to convert them explicitly.
>>>>
>>>> Converting them explicitly should be covered by the standard 
>>>> conversion rules, right?
>>>>
>>>> Do you want matrices to be implicitly convertible in non-operator 
>>>> contexts? Like, if you assign a float4x4 to an int4x4, should that 
>>>> implicitly convert the elements or be ill-formed?
>>>>
>>>>
>>> I think the current formulation allows for implicit conversions for 
>>> matrixes.
>>>
>>> But given the recent changes in the arithmetic context, it might be 
>>> better to only allow explicit conversions. Having implicit 
>>> conversions for non-operator contexts and not in operator contexts 
>>> seems a bit inconsistent. I think we should keep the conversion 
>>> rules based on the element types, but limit them to explicit 
>>> conversions. Does that make sense?\
>>
>> That makes sense to me.  If it’s actually a usability issue in 
>> practice, we can revisit, but I suspect that if we start strict 
>> we’ll avoid that.
>>
>>
>
> I’ve updated the Standard Conversion section in 
> https://reviews.llvm.org/D76612 with the following:
>
>   The standard conversions are extended as follows, with the exception 
> that for matrix types, standard conversions are not permissible for 
> assignments.
>
> Not sure if that’s the best way to put it, but hopefully the 
> intention is clear.

Yeah, that’s probably a bit misleading.  I’d say:

   The standard conversions are extended as follows.  Note that these 
conversions are intentionally not listed as satisfying the constraints 
for assignment, which is to say, they are only permitted as explicit 
casts, not as implicit conversions.

John.