[cfe-dev] Matrix Support in Clang

[John McCall via cfe-dev]

On 1 Apr 2020, at 13:15, Florian Hahn wrote:
> On Mar 26, 2020, at 23:02, John McCall <rjmccall at apple.com> wrote:
>> On 26 Mar 2020, at 18:21, Florian Hahn wrote:
>>
>> Arithmetic Conversions
>>
>> The usual arithmetic conversions are extended as follows.
>>
>> Insert at the start:
>>
>> * If either operand is of matrix type, apply the usual arithmetic 
>> conversions using its underlying element type. The resulting type is 
>> a matrix type with that underlying element type.
>>
>> This seems like a mistake, mostly because of the integer promotions. 
>> You really want short_matrix + short_matrix to yield an int_matrix, 
>> or -short_matrix to be an int_matrix? I would recommend that you 
>> specify this as working without integer promotion, so that the result 
>> of an operation two integer operations just has (1) the greater rank 
>> and (2) is unsigned if there’s a signedness mismatch and the signed 
>> type can’t express the full range of the unsigned type.
>>
>> The intention of choosing the rules for the underlying type was 
>> consistency with the existing behavior, but maybe it would be 
>> beneficial to forbid them. I think with both there might be source 
>> for confusion, but it might be simpler to not allow promotion.
>>
>> It’s an interesting question. In a totally different language, I 
>> would say that you shouldn’t allow mis-matched binary operations or 
>> implicit conversions, but that explicit casts should be able to do 
>> arbitrary element-wise conversions. That’s not really consistent 
>> with C’s normal behavior, though. It also might be really pedantic 
>> around e.g. scalar multiplication by a literal: would you have to 
>> write short4x4 * (short) 2? On the other hand, presumably you 
>> wouldn’t want float4x4 * 2.0 to yield a double4x4.
>>
>>
>
> 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.

John.


>  If there are no concerns about maintaining consistency with C’s 
> normal behavior, I think we should require the operand types to match 
> and I’ll update the patch with the draft spec accordingly 
> (https://reviews.llvm.org/D76612)
>
>> Matrix Type Element Access Operator
>>
>> An expression of the form `postfix-expression 
>> [expression][expression]` where the postfix-expression is of matrix 
>> type is a matrix element access expression. expression shall not be a 
>> comma expression, and shall be a prvalue of unscoped enumeration or 
>> integral type. Given the expression E1[E2][E3], the result is an 
>> lvalue of the same type as the underlying element type of the matrix 
>> that refers to the value at E2 row and E3 column in the matrix. The 
>> expression E1 is sequenced before E2 and E3. The expressions E2 and 
>> E3 are unsequenced.
>>
>> Note: We thought about providing an expression of the form 
>> `postfix-expression [expression]` to access columns of a matrix. We 
>> think that such an expression would be problematic once both column 
>> and row major matrixes are supported: depending on the memory layout, 
>> either accessing columns or rows can be done efficiently, but not 
>> both. Instead, we propose to provide builtins to extract rows and 
>> columns from a matrix. This makes the operations more explicit.
>>
>> Okay, so what happens if you do write matrix[0]?
>>
>> That is not supported. We should probably state explicitly that 
>> single index operators on matrix values are ill-defined or something 
>> like that?
>>
>> Yeah, you can say that incomplete subscripts can only be used as the 
>> base operand of another subscript. There’s a similar rule with 
>> member-function accesses in C++, which can only be the function 
>> operand of a call. You can enforce that rule reliably in Clang with a 
>> placeholder type.
>>
>>
> Great, thanks for pointing me to placeholder types! I’ve updated the 
> Clang patch adding matrix indexing expression to use a new placeholder 
> type to display a proper error message.
>
> Cheers,
> Florian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200401/ded02d60/attachment.html>