[cfe-dev] Matrix Support in Clang
John McCall via cfe-dev
cfe-dev at lists.llvm.org
Wed Apr 1 10:23:00 PDT 2020
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
> 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
>> 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?
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev