[cfe-dev] Matrix Support in Clang

[John McCall via cfe-dev]

On 2 Apr 2020, at 9:47, Florian Hahn wrote:

>> On Apr 1, 2020, at 20:48, Stephen Canon <scanon at apple.com> wrote:
>>
>>> On Apr 1, 2020, at 1:23 PM, John McCall via cfe-dev 
>>> <cfe-dev at lists.llvm.org> 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?

John.

>> For matrix operations implicit scalar conversions will be less 
>> important than they are for vectors, but they turned out to be really 
>> critical to have for vector programming. It may make sense to have 
>> them for matrices as well.
>>
>> The main issue for vectors is that there’s no way to get a sub-int 
>> literal in C (i.e. there’s no i8 suffix). This meant that simple 
>> vector code like, e.g.:
>>
>> 	uchar16 a, b;
>> 	uchar16 c = a & 0xf | b << 4;
>>
>> Had to be written as:
>>
>> 	uchar16 c = a & (uchar16)0xf | b << (uchar16)4;
>>
>> Which, well, it really sucked before we added the conversion rule. 
>> This sort of thing is less common for matrix math than vector math, 
>> but it probably makes sense to match the semantics for convenience 
>> and consistency; there haven’t really been a lot of drawbacks to 
>> the vector semantics.
>>
>> There should be no implicit conversions for matrix operands (and 
>> certainly not the C usual arithmetic conversions; approximately no 
>> one wants that behavior).
>>
>
> Thanks, I’ve updated the arithmetic conversion rules in  
> https://reviews.llvm.org/D76612  with the text below:
>
> * If both operands are of matrix type, no arithmetic conversion is 
> performed.
> * If one operand is of matrix type and the other operand is of an 
> integer or
>   floating point type, convert the integer or floating point operand 
> to the
>   underlying element type of the operand of matrix type.
>
> Cheers,
> Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200402/fc9a7e1f/attachment-0001.html>