<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 1 Apr 2020, at 13:15, Florian Hahn wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">On Mar 26, 2020, at 23:02, John McCall <rjmccall@apple.com> wrote:</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">On 26 Mar 2020, at 18:21, Florian Hahn wrote:<br>
<br>
Arithmetic Conversions<br>
<br>
The usual arithmetic conversions are extended as follows.<br>
<br>
Insert at the start:<br>
<br>
* 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
</p>
</blockquote><p dir="auto">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.<br>
<br>
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?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I think converting scalars is a necessary convenience in C given that e.g. literals are normally of type <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">int</code>, but yes, I think it’s fine to not implicitly convert matrices as long as you have a way to convert them explicitly.</p>
<p dir="auto">John.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto"> 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 (<a href="https://reviews.llvm.org/D76612" style="color:#777">https://reviews.llvm.org/D76612</a>)<br>
</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">Matrix Type Element Access Operator<br>
<br>
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.<br>
<br>
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.<br>
<br>
Okay, so what happens if you do write matrix[0]?<br>
<br>
That is not supported. We should probably state explicitly that single index operators on matrix values are ill-defined or something like that?<br>
<br>
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.<br>
<br>
</p>
</blockquote><p dir="auto">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.<br>
<br>
Cheers,<br>
Florian</p>
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>