[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7363ffe95f0a: [Matrix] Add draft specification for matrix 
support in Clang. (authored by fhahn).

Changed prior to commit:
  https://reviews.llvm.org/D76612?vs=258269=260367#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,285 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size 2-dimensional matrices as language values and perform arithmetic on
+them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Currently, the element type of a matrix is only permitted to be one of the
+following types:
+
+* an integer type (as in C2x 6.2.5p19), but excluding enumerated types and ``_Bool``
+* the standard floating types ``float`` or ``double``
+* a half-precision floating point type, if one is supported on the target
+
+Other types may be supported in the future.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the same and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of any real type (as in C2x 6.2.5p17) can be converted to a matrix type
+if it can be converted to the element type of the matrix. The result is a
+matrix where all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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 a real type,
+  convert the real type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn accepted this revision.
fhahn added a comment.
This revision is now accepted and ready to land.

Mark as accepted to make Phabricator/arc happy


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

Thanks, I plan to submit this on Monday and then make sure the patches on the 
clang side align with the draft.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

LGTM with one very minor fix.




Comment at: clang/docs/LanguageExtensions.rst:511
+*r = *a +  (*b * *c);
+  }
+

fhahn wrote:
> rjmccall wrote:
> > This is kindof an unnecessarily unreadable example.  I know you haven't 
> > decided on calling convention treatment yet, but maybe the leading example 
> > could be just a little ahead of the implementation and just take the 
> > matrices as arguments and then return the result.
> I wasn't sure if that would be fine, but it indeed makes things much more 
> readable. Updated.
Extra space after the `+`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

ping.

@rjmccall & @SjoerdMeijer thanks for all the comments. I hope they are no 
addressed adequately.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:511
+*r = *a +  (*b * *c);
+  }
+

rjmccall wrote:
> This is kindof an unnecessarily unreadable example.  I know you haven't 
> decided on calling convention treatment yet, but maybe the leading example 
> could be just a little ahead of the implementation and just take the matrices 
> as arguments and then return the result.
I wasn't sure if that would be fine, but it indeed makes things much more 
readable. Updated.



Comment at: clang/docs/MatrixTypes.rst:29
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > fhahn wrote:
> > > > SjoerdMeijer wrote:
> > > > > Now I am wondering if this requires some explanations on binary 
> > > > > operations for these implemenation-defined types? For example, for 
> > > > > `__fp16` and matrices with this `__fp16` element type, I assume 
> > > > > arithmetic is performed in at least the (single) floating-point 
> > > > > precision. So I guess in section "Arithmetic Conversions" a rule 
> > > > > needs to be added that the conversion of these implementation defined 
> > > > > types need to performed?
> > > > > 
> > > > I don't think we need to specifically discuss the implementation 
> > > > defined types here, as the conversions and binary operator definitions 
> > > > are framed in terms of the existing rules for the element types used. I 
> > > > am potentially missing something, but with the current wording the 
> > > > conversions for `__fp16` would use the conversion rules for that type 
> > > > and the binary operators would use the arithmetic rules for it.
> > > Yeah, for the scalar conversions / scalar operands, you should just say 
> > > that the source has to be a real type and not otherwise restrict it.  All 
> > > of those types should already be convertible to any matrix element type.
> > Thanks, I've updated the wording to ensure the scalar values are of a real 
> > type in the scalar -> matrix conversion and scalar, matrix binary operator 
> > contexts. I hope that is enough to clarify things.
> This would be clearer as something like:
> 
> > Currently, the element type of a matrix is only permitted to be one of the 
> > following types:
> >
> > - an integer type (as in C2x 6.2.5p19), but excluding enumerated types and 
> > `_Bool`
> > - a standard floating type (as in C2x 6.2.5p10)
> > - a half-precision floating point type, if one is supported on the target
> >
> > Other types may be supported in the future.
> 
> Although I don't know if you actually want to unconditionally support `long 
> double`; you might just want to say "the standard floating types `float` and 
> `double`".
That's much better, thanks! I've also applied your suggestion to exclude `long 
double` for now.



Comment at: clang/docs/MatrixTypes.rst:167
+operations on matrix types match the behavior of the elementwise operations
+in the corresponding expansions provided above.
+

rjmccall wrote:
> The expansions have a lot of statement boundaries that contraction wouldn't 
> be allowed across.  I'd suggest saying something like:
> 
> > Operations on floating-point matrices have the same rounding and 
> > floating-point environment behavior as ordinary floating-point operations 
> > in the expression's context.  For the purposes of floating-point 
> > contraction, all calculations done as part of a matrix operation are 
> > considered intermediate operations, and their results need not be rounded 
> > to the format of the element type until the final result in the containing 
> > expression.  This is subject to the normal restrictions on contraction, 
> > such as `#pragma STDC FP_CONTRACT`.
Updated, thanks!



Comment at: clang/docs/MatrixTypes.rst:216
+to ``row`` and ``col`` respectively. The parameter ``columnStride`` is optional
+and if ommitted ``row`` is used as ``columnStride``.
+

rjmccall wrote:
> "omitted".
> 
> I would expect these operands to have type either `size_t` or `ptrdiff_t`.  
> Of course it only really matters for `columnStride`.
> "omitted".

Done, thanks!

> I would expect these operands to have type either size_t or ptrdiff_t. Of 
> course it only really matters for columnStride.
Yes, I update them to size_t. This should give the implementations the most 
freedom with respect to choosing the implementation defined limits of 
rows/columns. `size_t` also makes the most sense for the stride I think, as it 
is required to be >= the number of rows in the matrix.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 258269.
fhahn marked 9 inline comments as done.
fhahn added a comment.

Update wordings as suggested, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,285 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size 2-dimensional matrices as language values and perform arithmetic on
+them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Currently, the element type of a matrix is only permitted to be one of the
+following types:
+
+* an integer type (as in C2x 6.2.5p19), but excluding enumerated types and ``_Bool``
+* the standard floating types ``float`` or ``double``
+* a half-precision floating point type, if one is supported on the target
+
+Other types may be supported in the future.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the same and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of any real type (as in C2x 6.2.5p17) can be converted to a matrix type
+if it can be converted to the element type of the matrix. The result is a
+matrix where all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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 a real type,
+  convert the real type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:511
+*r = *a +  (*b * *c);
+  }
+

This is kindof an unnecessarily unreadable example.  I know you haven't decided 
on calling convention treatment yet, but maybe the leading example could be 
just a little ahead of the implementation and just take the matrices as 
arguments and then return the result.



Comment at: clang/docs/MatrixTypes.rst:29
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.

fhahn wrote:
> rjmccall wrote:
> > fhahn wrote:
> > > SjoerdMeijer wrote:
> > > > Now I am wondering if this requires some explanations on binary 
> > > > operations for these implemenation-defined types? For example, for 
> > > > `__fp16` and matrices with this `__fp16` element type, I assume 
> > > > arithmetic is performed in at least the (single) floating-point 
> > > > precision. So I guess in section "Arithmetic Conversions" a rule needs 
> > > > to be added that the conversion of these implementation defined types 
> > > > need to performed?
> > > > 
> > > I don't think we need to specifically discuss the implementation defined 
> > > types here, as the conversions and binary operator definitions are framed 
> > > in terms of the existing rules for the element types used. I am 
> > > potentially missing something, but with the current wording the 
> > > conversions for `__fp16` would use the conversion rules for that type and 
> > > the binary operators would use the arithmetic rules for it.
> > Yeah, for the scalar conversions / scalar operands, you should just say 
> > that the source has to be a real type and not otherwise restrict it.  All 
> > of those types should already be convertible to any matrix element type.
> Thanks, I've updated the wording to ensure the scalar values are of a real 
> type in the scalar -> matrix conversion and scalar, matrix binary operator 
> contexts. I hope that is enough to clarify things.
This would be clearer as something like:

> Currently, the element type of a matrix is only permitted to be one of the 
> following types:
>
> - an integer type (as in C2x 6.2.5p19), but excluding enumerated types and 
> `_Bool`
> - a standard floating type (as in C2x 6.2.5p10)
> - a half-precision floating point type, if one is supported on the target
>
> Other types may be supported in the future.

Although I don't know if you actually want to unconditionally support `long 
double`; you might just want to say "the standard floating types `float` and 
`double`".



Comment at: clang/docs/MatrixTypes.rst:62
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the size and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is

s/size/same/



Comment at: clang/docs/MatrixTypes.rst:66
+
+A value of a real type can be converted to a matrix type if it can be
+converted to the element type of the matrix. The result is a matrix where

"A value of any real type (as in C2x 6.2.5p17) can be converted..."



Comment at: clang/docs/MatrixTypes.rst:167
+operations on matrix types match the behavior of the elementwise operations
+in the corresponding expansions provided above.
+

The expansions have a lot of statement boundaries that contraction wouldn't be 
allowed across.  I'd suggest saying something like:

> Operations on floating-point matrices have the same rounding and 
> floating-point environment behavior as ordinary floating-point operations in 
> the expression's context.  For the purposes of floating-point contraction, 
> all calculations done as part of a matrix operation are considered 
> intermediate operations, and their results need not be rounded to the format 
> of the element type until the final result in the containing expression.  
> This is subject to the normal restrictions on contraction, such as `#pragma 
> STDC FP_CONTRACT`.



Comment at: clang/docs/MatrixTypes.rst:216
+to ``row`` and ``col`` respectively. The parameter ``columnStride`` is optional
+and if ommitted ``row`` is used as ``columnStride``.
+

"omitted".

I would expect these operands to have type either `size_t` or `ptrdiff_t`.  Of 
course it only really matters for `columnStride`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn marked an inline comment as done.
fhahn added inline comments.



Comment at: clang/docs/MatrixTypes.rst:29
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.

rjmccall wrote:
> fhahn wrote:
> > SjoerdMeijer wrote:
> > > Now I am wondering if this requires some explanations on binary 
> > > operations for these implemenation-defined types? For example, for 
> > > `__fp16` and matrices with this `__fp16` element type, I assume 
> > > arithmetic is performed in at least the (single) floating-point 
> > > precision. So I guess in section "Arithmetic Conversions" a rule needs to 
> > > be added that the conversion of these implementation defined types need 
> > > to performed?
> > > 
> > I don't think we need to specifically discuss the implementation defined 
> > types here, as the conversions and binary operator definitions are framed 
> > in terms of the existing rules for the element types used. I am potentially 
> > missing something, but with the current wording the conversions for 
> > `__fp16` would use the conversion rules for that type and the binary 
> > operators would use the arithmetic rules for it.
> Yeah, for the scalar conversions / scalar operands, you should just say that 
> the source has to be a real type and not otherwise restrict it.  All of those 
> types should already be convertible to any matrix element type.
Thanks, I've updated the wording to ensure the scalar values are of a real type 
in the scalar -> matrix conversion and scalar, matrix binary operator contexts. 
I hope that is enough to clarify things.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 258179.
fhahn added a comment.

Update wording to allow any real type for scalar -> matrix conversion and 
scalar,matrix binary ops.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,272 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size 2-dimensional matrices as language values and perform arithmetic on
+them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types, ``_Bool``, and the fixed-point types or an
+implementation-defined half-precision floating point type, otherwise the
+program is ill-formed.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the size and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of a real type can be converted to a matrix type if it can be
+converted to the element type of the matrix. The result is a matrix where
+all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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 a real type,
+  convert the real type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row and column in
+the matrix.
+
+Programs containing a single subscript expression into a matrix are ill-formed.
+
+**Note**: 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/docs/MatrixTypes.rst:29
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.

fhahn wrote:
> SjoerdMeijer wrote:
> > Now I am wondering if this requires some explanations on binary operations 
> > for these implemenation-defined types? For example, for `__fp16` and 
> > matrices with this `__fp16` element type, I assume arithmetic is performed 
> > in at least the (single) floating-point precision. So I guess in section 
> > "Arithmetic Conversions" a rule needs to be added that the conversion of 
> > these implementation defined types need to performed?
> > 
> I don't think we need to specifically discuss the implementation defined 
> types here, as the conversions and binary operator definitions are framed in 
> terms of the existing rules for the element types used. I am potentially 
> missing something, but with the current wording the conversions for `__fp16` 
> would use the conversion rules for that type and the binary operators would 
> use the arithmetic rules for it.
Yeah, for the scalar conversions / scalar operands, you should just say that 
the source has to be a real type and not otherwise restrict it.  All of those 
types should already be convertible to any matrix element type.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/docs/MatrixTypes.rst:79
+  floating point type, convert the integer or floating point operand to the
+  underlying element type of the operand of matrix type.
+

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > You should standardize on one term and then be clear what you mean by it. 
> > >  Here you're saying "integer or floating point type", but elsewhere you 
> > > use "arithmetic type".  Unfortunately, the standard terms mean somewhat 
> > > different things in different standards: "integer" includes enums in C 
> > > but not in C++, "arithmetic" doesn't include complex types in C++ 
> > > (although it does by extension in Clang), etc.  I think for operands you 
> > > probably want arithmetic types in the real domain (which in Clang is 
> > > `isRealType()`).  However, you'll want to use a narrower term for the 
> > > restriction on element types because Clang does support fixed-point 
> > > types, but you probably don't want to support matrices of them quite yet 
> > > (and you may not want to allow matrices of bools, either).
> > > 
> > > Also, your description of the scalar conversions no longer promotes them 
> > > to matrix type.
> > > You should standardize on one term and then be clear what you mean by it. 
> > > Here you're saying "integer or floating point type", but elsewhere you 
> > > use "arithmetic type". Unfortunately, the standard terms mean somewhat 
> > > different things in different standards: "integer" includes enums in C 
> > > but not in C++, "arithmetic" doesn't include complex types in C++ 
> > > (although it does by extension in Clang), etc. I think for operands you 
> > > probably want arithmetic types in the real domain (which in Clang is 
> > > isRealType()). However, you'll want to use a narrower term for the 
> > > restriction on element types because Clang does support fixed-point 
> > > types, but you probably don't want to support matrices of them quite yet 
> > > (and you may not want to allow matrices of bools, either).
> > 
> > I've added the following to the Matrix Type section:
> > ` A *matrix element type* must be a real type (as in C99 6.2.5p17) 
> > excluding enumeration types or an implementation-defined half-precision 
> > floating point type, otherwise the program is ill-formed.`
> > 
> > Other places are updated to use `a valid matrix element type` instead.
> > 
> > I think we explicitly want to allow half-precision types (like __fp16 and 
> > Float16 in Clang). I think by referring to real type as in the C99 spec, we 
> > naturally exclude Clang's fixed-point types and bool, right? 
> > 
> > > Also, your description of the scalar conversions no longer promotes them 
> > > to matrix type.
> > 
> > Right, I think we can just refer to the standard conversion rules here, as 
> > in
> > 
> > `If one operand is of matrix type and the other operand is of a valid 
> > matrix element type, convert the non-matrix type operand to the matrix type 
> > according to the standard conversion rules.`
> > I think we explicitly want to allow half-precision types (like __fp16 and 
> > Float16 in Clang). I think by referring to real type as in the C99 spec, we 
> > naturally exclude Clang's fixed-point types and bool, right?
> 
> C says:
> 
> > The integer and real floating types are collectively called *real types*.
> 
> > The type `char`, the signed and unsigned integer types, and the enumerated 
> > types are collectively called *integer types*.
> 
> > The standard and extended unsigned integer types are collectively called 
> > *unsigned integer types*.
> 
> > The type `_Bool` and the unsigned integer types that correspond to the 
> > standard signed integer types are the *standard unsigned integer types*.
> 
> Embedded C (TR 18037) says:
> 
> > Clause 6.2.5 - Types, paragraph 17: change last sentence as follows.
> >
> > Integer, fixed-point and real floating types are collectively called *real 
> > types*.
> 
> So you'll have to explicitly exclude enumerated types, `_Bool`, and the 
> fixed-point types.
Ah thanks, I missed `TR 18037`. Sorry about that! I've updated the wording as 
suggested.  



Comment at: clang/docs/MatrixTypes.rst:27
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point

SjoerdMeijer wrote:
> fhahn wrote:
> > SjoerdMeijer wrote:
> > > fhahn wrote:
> > > > SjoerdMeijer wrote:
> > > > > above you're using *element type* and here *matrix element type*. 
> > > > > Since hopefully we're talking about the same things, "matrix *element 
> > > > > type*" would be more consistent.
> > > > > 
> > > > > But this is just a nit, my main question is about the types:
> > > > > why not e.g. define this to be the C11 types, that include _FloatN 
> > > > > types, so that we can 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 257741.
fhahn marked 3 inline comments as done.
fhahn added a comment.

Update list of types excluded from real types, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,272 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size 2-dimensional matrices as language values and perform arithmetic on
+them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types, ``_Bool``, and the fixed-point types or an
+implementation-defined half-precision floating point type, otherwise the
+program is ill-formed.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the size and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of non-matrix type can be converted to a matrix type if it can be
+converted to the element type of the matrix. The result is a matrix where
+all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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 a valid matrix
+  element type, convert the non-matrix type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row and column in
+the matrix.
+
+Programs containing a single subscript expression into a matrix are 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/docs/MatrixTypes.rst:27
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point

fhahn wrote:
> SjoerdMeijer wrote:
> > fhahn wrote:
> > > SjoerdMeijer wrote:
> > > > above you're using *element type* and here *matrix element type*. Since 
> > > > hopefully we're talking about the same things, "matrix *element type*" 
> > > > would be more consistent.
> > > > 
> > > > But this is just a nit, my main question is about the types:
> > > > why not e.g. define this to be the C11 types, that include _FloatN 
> > > > types, so that we can include N=16? Or is this intentionally omitted? I 
> > > > haven't even checked if this is supported in the architecture 
> > > > extension, but might make sense? And also, an element type cannot be an 
> > > > integer type? 
> > > > 
> > > >  
> > > > above you're using *element type* and here *matrix element type*. Since 
> > > > hopefully we're talking about the same things, "matrix *element type*" 
> > > > would be more consistent.
> > > 
> > > Yes it is referring to the same thing. I had a look at most uses, and in 
> > > most cases `element type` is used to refer to the element type of a given 
> > > matrix type. In that context it seems a bit verbose to use `matrix 
> > > element type`, although I am more than happy to change that if it helps 
> > > with clarifying things.
> > > 
> > > I intentionally used `matrix element type` in `Arithmetic Conversions`, 
> > > because there it is standing on its own and refers exactly to the set of 
> > > types defined as valid matrix element types here.
> > > 
> > > > why not e.g. define this to be the C11 types, that include _FloatN 
> > > > types, so that we can include N=16? Or is this intentionally omitted? I 
> > > > haven't even checked if this is supported in the architecture 
> > > > extension, but might make sense?
> > > 
> > > I couldn't find any reference to _FloatN types in the C11 draft version I 
> > > checked. Do you by any chance have a reference to the _FloatN types?
> > > 
> > > > And also, an element type cannot be an integer type?
> > > 
> > > The current definition should include it (real types include integer and 
> > > real floating point types according to  C99 6.2.5p17). I don't think 
> > > there is any reason to exclude them I think.
> > >>why not e.g. define this to be the C11 types, that include _FloatN 
> > >> types, so that we can include N=16? Or is this intentionally omitted? I 
> > >> haven't even checked if this is supported in the architecture extension, 
> > >> but might make sense?
> > >>
> > > I couldn't find any reference to _FloatN types in the C11 draft version I 
> > > checked. Do you by any chance have a reference to the _FloatN types?
> > 
> > Sorry, I was a bit imprecise here, it's an extension of C11: ISO/IEC TS 
> > 18661-3:2015.
> > My thinking was it would be cool to support the "proper" half-precision 
> > type. I thought about this, because of "or an implementation-defined 
> > half-precision" mentioned just below here, of which probably __fp16 is an 
> > example.  If you refer to the C99 types, you probably don't even need to 
> > mention this (although it won't do any harm)?
> > 
> > >>  And also, an element type cannot be an integer type?
> > >
> > > The current definition should include it (real types include integer and 
> > > real floating point types according to C99 6.2.5p17). I don't think there 
> > > is any reason to exclude them I think.
> > 
> > Ok, cheers, wrote this from memory (forgot this), and didn't check the 
> > standard.
> > Sorry, I was a bit imprecise here, it's an extension of C11: ISO/IEC TS 
> > 18661-3:2015.
> > My thinking was it would be cool to support the "proper" half-precision 
> > type. I thought about this, because of "or an implementation-defined 
> > half-precision" mentioned just below here, of which probably __fp16 is an 
> > example. If you refer to the C99 types, you probably don't even need to 
> > mention this (although it won't do any harm)?
> 
> I am not sure what the exact wording should be, but the intention is to 
> include both __fp16 and _Float16. I was hoping that would be covered as is, 
> but I would be happy to clarify (unfortunately it is not entirely clear to me 
> how to best word this)
Ah, okay, I got it. How about a simple enumeration, e.g.:  

  A *matrix element type* must be a C99 real type, excluding enumeration types, 
the C11 ISO/IEC TS 18661 _Float16 type, the ARM ACLE __fp16 type, or an 
implementation-defined half-precision floating point type, otherwise the 
program is ill-formed.



Comment at: clang/docs/MatrixTypes.rst:29
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/docs/MatrixTypes.rst:79
+  floating point type, convert the integer or floating point operand to the
+  underlying element type of the operand of matrix type.
+

fhahn wrote:
> rjmccall wrote:
> > You should standardize on one term and then be clear what you mean by it.  
> > Here you're saying "integer or floating point type", but elsewhere you use 
> > "arithmetic type".  Unfortunately, the standard terms mean somewhat 
> > different things in different standards: "integer" includes enums in C but 
> > not in C++, "arithmetic" doesn't include complex types in C++ (although it 
> > does by extension in Clang), etc.  I think for operands you probably want 
> > arithmetic types in the real domain (which in Clang is `isRealType()`).  
> > However, you'll want to use a narrower term for the restriction on element 
> > types because Clang does support fixed-point types, but you probably don't 
> > want to support matrices of them quite yet (and you may not want to allow 
> > matrices of bools, either).
> > 
> > Also, your description of the scalar conversions no longer promotes them to 
> > matrix type.
> > You should standardize on one term and then be clear what you mean by it. 
> > Here you're saying "integer or floating point type", but elsewhere you use 
> > "arithmetic type". Unfortunately, the standard terms mean somewhat 
> > different things in different standards: "integer" includes enums in C but 
> > not in C++, "arithmetic" doesn't include complex types in C++ (although it 
> > does by extension in Clang), etc. I think for operands you probably want 
> > arithmetic types in the real domain (which in Clang is isRealType()). 
> > However, you'll want to use a narrower term for the restriction on element 
> > types because Clang does support fixed-point types, but you probably don't 
> > want to support matrices of them quite yet (and you may not want to allow 
> > matrices of bools, either).
> 
> I've added the following to the Matrix Type section:
> ` A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding 
> enumeration types or an implementation-defined half-precision floating point 
> type, otherwise the program is ill-formed.`
> 
> Other places are updated to use `a valid matrix element type` instead.
> 
> I think we explicitly want to allow half-precision types (like __fp16 and 
> Float16 in Clang). I think by referring to real type as in the C99 spec, we 
> naturally exclude Clang's fixed-point types and bool, right? 
> 
> > Also, your description of the scalar conversions no longer promotes them to 
> > matrix type.
> 
> Right, I think we can just refer to the standard conversion rules here, as in
> 
> `If one operand is of matrix type and the other operand is of a valid matrix 
> element type, convert the non-matrix type operand to the matrix type 
> according to the standard conversion rules.`
> I think we explicitly want to allow half-precision types (like __fp16 and 
> Float16 in Clang). I think by referring to real type as in the C99 spec, we 
> naturally exclude Clang's fixed-point types and bool, right?

C says:

> The integer and real floating types are collectively called *real types*.

> The type `char`, the signed and unsigned integer types, and the enumerated 
> types are collectively called *integer types*.

> The standard and extended unsigned integer types are collectively called 
> *unsigned integer types*.

> The type `_Bool` and the unsigned integer types that correspond to the 
> standard signed integer types are the *standard unsigned integer types*.

Embedded C (TR 18037) says:

> Clause 6.2.5 - Types, paragraph 17: change last sentence as follows.
>
> Integer, fixed-point and real floating types are collectively called *real 
> types*.

So you'll have to explicitly exclude enumerated types, `_Bool`, and the 
fixed-point types.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn marked an inline comment as done.
fhahn added inline comments.



Comment at: clang/docs/MatrixTypes.rst:27
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point

SjoerdMeijer wrote:
> fhahn wrote:
> > SjoerdMeijer wrote:
> > > above you're using *element type* and here *matrix element type*. Since 
> > > hopefully we're talking about the same things, "matrix *element type*" 
> > > would be more consistent.
> > > 
> > > But this is just a nit, my main question is about the types:
> > > why not e.g. define this to be the C11 types, that include _FloatN types, 
> > > so that we can include N=16? Or is this intentionally omitted? I haven't 
> > > even checked if this is supported in the architecture extension, but 
> > > might make sense? And also, an element type cannot be an integer type? 
> > > 
> > >  
> > > above you're using *element type* and here *matrix element type*. Since 
> > > hopefully we're talking about the same things, "matrix *element type*" 
> > > would be more consistent.
> > 
> > Yes it is referring to the same thing. I had a look at most uses, and in 
> > most cases `element type` is used to refer to the element type of a given 
> > matrix type. In that context it seems a bit verbose to use `matrix element 
> > type`, although I am more than happy to change that if it helps with 
> > clarifying things.
> > 
> > I intentionally used `matrix element type` in `Arithmetic Conversions`, 
> > because there it is standing on its own and refers exactly to the set of 
> > types defined as valid matrix element types here.
> > 
> > > why not e.g. define this to be the C11 types, that include _FloatN types, 
> > > so that we can include N=16? Or is this intentionally omitted? I haven't 
> > > even checked if this is supported in the architecture extension, but 
> > > might make sense?
> > 
> > I couldn't find any reference to _FloatN types in the C11 draft version I 
> > checked. Do you by any chance have a reference to the _FloatN types?
> > 
> > > And also, an element type cannot be an integer type?
> > 
> > The current definition should include it (real types include integer and 
> > real floating point types according to  C99 6.2.5p17). I don't think there 
> > is any reason to exclude them I think.
> >>why not e.g. define this to be the C11 types, that include _FloatN 
> >> types, so that we can include N=16? Or is this intentionally omitted? I 
> >> haven't even checked if this is supported in the architecture extension, 
> >> but might make sense?
> >>
> > I couldn't find any reference to _FloatN types in the C11 draft version I 
> > checked. Do you by any chance have a reference to the _FloatN types?
> 
> Sorry, I was a bit imprecise here, it's an extension of C11: ISO/IEC TS 
> 18661-3:2015.
> My thinking was it would be cool to support the "proper" half-precision type. 
> I thought about this, because of "or an implementation-defined 
> half-precision" mentioned just below here, of which probably __fp16 is an 
> example.  If you refer to the C99 types, you probably don't even need to 
> mention this (although it won't do any harm)?
> 
> >>  And also, an element type cannot be an integer type?
> >
> > The current definition should include it (real types include integer and 
> > real floating point types according to C99 6.2.5p17). I don't think there 
> > is any reason to exclude them I think.
> 
> Ok, cheers, wrote this from memory (forgot this), and didn't check the 
> standard.
> Sorry, I was a bit imprecise here, it's an extension of C11: ISO/IEC TS 
> 18661-3:2015.
> My thinking was it would be cool to support the "proper" half-precision type. 
> I thought about this, because of "or an implementation-defined 
> half-precision" mentioned just below here, of which probably __fp16 is an 
> example. If you refer to the C99 types, you probably don't even need to 
> mention this (although it won't do any harm)?

I am not sure what the exact wording should be, but the intention is to include 
both __fp16 and _Float16. I was hoping that would be covered as is, but I would 
be happy to clarify (unfortunately it is not entirely clear to me how to best 
word this)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/docs/MatrixTypes.rst:27
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point

fhahn wrote:
> SjoerdMeijer wrote:
> > above you're using *element type* and here *matrix element type*. Since 
> > hopefully we're talking about the same things, "matrix *element type*" 
> > would be more consistent.
> > 
> > But this is just a nit, my main question is about the types:
> > why not e.g. define this to be the C11 types, that include _FloatN types, 
> > so that we can include N=16? Or is this intentionally omitted? I haven't 
> > even checked if this is supported in the architecture extension, but might 
> > make sense? And also, an element type cannot be an integer type? 
> > 
> >  
> > above you're using *element type* and here *matrix element type*. Since 
> > hopefully we're talking about the same things, "matrix *element type*" 
> > would be more consistent.
> 
> Yes it is referring to the same thing. I had a look at most uses, and in most 
> cases `element type` is used to refer to the element type of a given matrix 
> type. In that context it seems a bit verbose to use `matrix element type`, 
> although I am more than happy to change that if it helps with clarifying 
> things.
> 
> I intentionally used `matrix element type` in `Arithmetic Conversions`, 
> because there it is standing on its own and refers exactly to the set of 
> types defined as valid matrix element types here.
> 
> > why not e.g. define this to be the C11 types, that include _FloatN types, 
> > so that we can include N=16? Or is this intentionally omitted? I haven't 
> > even checked if this is supported in the architecture extension, but might 
> > make sense?
> 
> I couldn't find any reference to _FloatN types in the C11 draft version I 
> checked. Do you by any chance have a reference to the _FloatN types?
> 
> > And also, an element type cannot be an integer type?
> 
> The current definition should include it (real types include integer and real 
> floating point types according to  C99 6.2.5p17). I don't think there is any 
> reason to exclude them I think.
>>why not e.g. define this to be the C11 types, that include _FloatN types, 
>> so that we can include N=16? Or is this intentionally omitted? I haven't 
>> even checked if this is supported in the architecture extension, but might 
>> make sense?
>>
> I couldn't find any reference to _FloatN types in the C11 draft version I 
> checked. Do you by any chance have a reference to the _FloatN types?

Sorry, I was a bit imprecise here, it's an extension of C11: ISO/IEC TS 
18661-3:2015.
My thinking was it would be cool to support the "proper" half-precision type. I 
thought about this, because of "or an implementation-defined half-precision" 
mentioned just below here, of which probably __fp16 is an example.  If you 
refer to the C99 types, you probably don't even need to mention this (although 
it won't do any harm)?

>>  And also, an element type cannot be an integer type?
>
> The current definition should include it (real types include integer and real 
> floating point types according to C99 6.2.5p17). I don't think there is any 
> reason to exclude them I think.

Ok, cheers, wrote this from memory (forgot this), and didn't check the standard.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn marked 3 inline comments as done.
fhahn added inline comments.



Comment at: clang/docs/MatrixTypes.rst:12
+fixed-size matrices as language values and perform arithmetic on them.
+
+This feature is currently experimental, and both its design and its

SjoerdMeijer wrote:
> Would it be good to set expectations here or in the section below: define 
> that we're talking about 2-dimensional m × n matrices?
I've changed it to `fixed-size 2-dimensional matrices`. I think the type 
definition below should be already clear enough about being 2 dimensional.



Comment at: clang/docs/MatrixTypes.rst:27
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point

SjoerdMeijer wrote:
> above you're using *element type* and here *matrix element type*. Since 
> hopefully we're talking about the same things, "matrix *element type*" would 
> be more consistent.
> 
> But this is just a nit, my main question is about the types:
> why not e.g. define this to be the C11 types, that include _FloatN types, so 
> that we can include N=16? Or is this intentionally omitted? I haven't even 
> checked if this is supported in the architecture extension, but might make 
> sense? And also, an element type cannot be an integer type? 
> 
>  
> above you're using *element type* and here *matrix element type*. Since 
> hopefully we're talking about the same things, "matrix *element type*" would 
> be more consistent.

Yes it is referring to the same thing. I had a look at most uses, and in most 
cases `element type` is used to refer to the element type of a given matrix 
type. In that context it seems a bit verbose to use `matrix element type`, 
although I am more than happy to change that if it helps with clarifying things.

I intentionally used `matrix element type` in `Arithmetic Conversions`, because 
there it is standing on its own and refers exactly to the set of types defined 
as valid matrix element types here.

> why not e.g. define this to be the C11 types, that include _FloatN types, so 
> that we can include N=16? Or is this intentionally omitted? I haven't even 
> checked if this is supported in the architecture extension, but might make 
> sense?

I couldn't find any reference to _FloatN types in the C11 draft version I 
checked. Do you by any chance have a reference to the _FloatN types?

> And also, an element type cannot be an integer type?

The current definition should include it (real types include integer and real 
floating point types according to  C99 6.2.5p17). I don't think there is any 
reason to exclude them I think.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 257309.
fhahn added a comment.

Drop another instance of underlying element type.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,271 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size 2-dimensional matrices as language values and perform arithmetic on
+them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the size and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of non-matrix type can be converted to a matrix type if it can be
+converted to the element type of the matrix. The result is a matrix where
+all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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 a valid matrix
+  element type, convert the non-matrix type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row and column in
+the matrix.
+
+Programs containing a single subscript expression into a matrix are ill-formed.
+
+**Note**: We considered providing an expression of the form

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 257304.
fhahn added a comment.

Fix typo, remove a 2 places where `underlying` element type was used, move C 
portion of the example to LanguageExtensions.rst, drop the rest of the example.
:


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,271 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size 2-dimensional matrices as language values and perform arithmetic on
+them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the size and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of non-matrix type can be converted to a matrix type if it can be
+converted to the element type of the matrix. The result is a matrix where
+all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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 a valid matrix
+  element type, convert the non-matrix type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row and column in
+the matrix.
+
+Programs containing a single subscript 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/docs/MatrixTypes.rst:12
+fixed-size matrices as language values and perform arithmetic on them.
+
+This feature is currently experimental, and both its design and its

Would it be good to set expectations here or in the section below: define that 
we're talking about 2-dimensional m × n matrices?



Comment at: clang/docs/MatrixTypes.rst:25
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element ype*. The
+internal layout, overall size and alignment are implementation-defined.

typo: ype -> type



Comment at: clang/docs/MatrixTypes.rst:27
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point

above you're using *element type* and here *matrix element type*. Since 
hopefully we're talking about the same things, "matrix *element type*" would be 
more consistent.

But this is just a nit, my main question is about the types:
why not e.g. define this to be the C11 types, that include _FloatN types, so 
that we can include N=16? Or is this intentionally omitted? I haven't even 
checked if this is supported in the architecture extension, but might make 
sense? And also, an element type cannot be an integer type? 

 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 257259.
fhahn marked an inline comment as done.
fhahn added a comment.

Rename __builtin_matrix_columnwise_{load,store} => 
__builtin_matrix_column_major_{load,store}


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,323 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size matrices as language values and perform arithmetic on them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element ype*. The
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the size and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of non-matrix type can be converted to a matrix type if it can be
+converted to the element type of the matrix. The result is a matrix where
+all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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 a valid matrix
+  element type, convert the non-matrix type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row and column in
+the matrix.
+
+Programs containing a single subscript expression into a matrix are ill-formed.
+

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/docs/MatrixTypes.rst:79
+  floating point type, convert the integer or floating point operand to the
+  underlying element type of the operand of matrix type.
+

rjmccall wrote:
> You should standardize on one term and then be clear what you mean by it.  
> Here you're saying "integer or floating point type", but elsewhere you use 
> "arithmetic type".  Unfortunately, the standard terms mean somewhat different 
> things in different standards: "integer" includes enums in C but not in C++, 
> "arithmetic" doesn't include complex types in C++ (although it does by 
> extension in Clang), etc.  I think for operands you probably want arithmetic 
> types in the real domain (which in Clang is `isRealType()`).  However, you'll 
> want to use a narrower term for the restriction on element types because 
> Clang does support fixed-point types, but you probably don't want to support 
> matrices of them quite yet (and you may not want to allow matrices of bools, 
> either).
> 
> Also, your description of the scalar conversions no longer promotes them to 
> matrix type.
> You should standardize on one term and then be clear what you mean by it. 
> Here you're saying "integer or floating point type", but elsewhere you use 
> "arithmetic type". Unfortunately, the standard terms mean somewhat different 
> things in different standards: "integer" includes enums in C but not in C++, 
> "arithmetic" doesn't include complex types in C++ (although it does by 
> extension in Clang), etc. I think for operands you probably want arithmetic 
> types in the real domain (which in Clang is isRealType()). However, you'll 
> want to use a narrower term for the restriction on element types because 
> Clang does support fixed-point types, but you probably don't want to support 
> matrices of them quite yet (and you may not want to allow matrices of bools, 
> either).

I've added the following to the Matrix Type section:
` A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding 
enumeration types or an implementation-defined half-precision floating point 
type, otherwise the program is ill-formed.`

Other places are updated to use `a valid matrix element type` instead.

I think we explicitly want to allow half-precision types (like __fp16 and 
Float16 in Clang). I think by referring to real type as in the C99 spec, we 
naturally exclude Clang's fixed-point types and bool, right? 

> Also, your description of the scalar conversions no longer promotes them to 
> matrix type.

Right, I think we can just refer to the standard conversion rules here, as in

`If one operand is of matrix type and the other operand is of a valid matrix 
element type, convert the non-matrix type operand to the matrix type according 
to the standard conversion rules.`



Comment at: clang/docs/MatrixTypes.rst:123
+  M2 are of arithmetic type, they are broadcast to matrices here. — end note ]
+* The matrix types of M1 and M2 shall have the same number of rows and columns.
+* The result is equivalent to Res in the following where col is the number of

rjmccall wrote:
> They also have to have the same element types, right?  So they have to be the 
> same types?
Yes, for 2 operands of a matrix type, they should be the same types now. 
Changed to  `M1 and M2 shall be of the same matrix type.`



Comment at: clang/docs/MatrixTypes.rst:138
+* The type of ``M1`` shall have the same number of columns as the type of 
``M2`` has
+  rows.
+* The resulting type, ``MTy``, is the result of applying the usual arithmetic

rjmccall wrote:
> Same point about element types.
Added 
>The element types of ``M1`` and ``M2`` shall be the same type



Comment at: clang/docs/MatrixTypes.rst:141
+  conversions to ``M1`` and ``M2``, but with the same number of rows as M1’s 
matrix
+  type and the same number of columns as M2’s matrix type.
+* The result is equivalent to ``Res`` in the following where ``EltTy`` is the

rjmccall wrote:
> The easier way to put this now is that it's a matrix type whose element type 
> is the common element type, but with the number of rows of `M1` and the 
> number of columns of `M2`.
Replaced with 

> The resulting type, `MTy`, is a matrix type with the common element type, the 
> number of rows of `M1` and the number of columns of `M2`.




Comment at: clang/docs/MatrixTypes.rst:152
+  EltTy Elt = 0;
+  for (int K = 0; K < inner; ++K) {
+Elt += M1[R][K] * M2[K][C];

rjmccall wrote:
> `inner` is not defined.
Should be something like ` and ``inner`` is the number of columns of ``M1```



Comment at: clang/docs/MatrixTypes.rst:164
+Clang option to override this behavior and allow contraction of those
+operations (e.g. *-ffp-contract=matrix*).
+

rjmccall wrote:
> This is about rounding, not 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 257253.
fhahn marked 8 inline comments as done.
fhahn added a comment.

Address latest comments, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,323 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size matrices as language values and perform arithmetic on them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element ype*. The
+internal layout, overall size and alignment are implementation-defined.
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the size and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of non-matrix type can be converted to a matrix type if it can be
+converted to the element type of the matrix. The result is a matrix where
+all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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 a valid matrix
+  element type, convert the non-matrix type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row and column in
+the matrix.
+
+Programs containing a single subscript expression into a matrix are ill-formed.
+
+**Note**: We considered providing an expression of the form

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/docs/MatrixSupport.rst:211
+
+``M __builtin_matrix_column_load(T *ptr, int row, int col, int stride)``
+

fhahn wrote:
> rjmccall wrote:
> > This name sounds like it's loading a column, when I think you're saying 
> > that the memory has to be in column-major order.
> > 
> > I would call `stride` something like `columnStride` to make it clear that 
> > it's the stride between columns, as opposed to a stride between the 
> > elements within a column, which is also something that's theoretically 
> > interesting.
> > 
> > Should `stride` be an optional argument to make it easier to write the (I 
> > expect) common case where the matrix is dense?
> > This name sounds like it's loading a column, when I think you're saying 
> > that the memory has to be in column-major order.
> 
> Yes that is correct. Maybe __builtin_matrix_columnwise_load would be slightly 
> better?
> 
> > Should stride be an optional argument to make it easier to write the (I 
> > expect) common case where the matrix is dense?
> Yes that would be very convenient, especially now that casting between 
> element wise pointers and matrixes is not allowed. I've added a sentence to 
> the remarks for both the load and store builtins.
> Yes that is correct. Maybe __builtin_matrix_columnwise_load would be slightly 
> better?

The term of art is "column-major"; I don't think avoiding an "extra word" is a 
good enough reason to invent something else.  
`__builtin_matrix_column_major_load` sounds fine to me.



Comment at: clang/docs/MatrixTypes.rst:79
+  floating point type, convert the integer or floating point operand to the
+  underlying element type of the operand of matrix type.
+

You should standardize on one term and then be clear what you mean by it.  Here 
you're saying "integer or floating point type", but elsewhere you use 
"arithmetic type".  Unfortunately, the standard terms mean somewhat different 
things in different standards: "integer" includes enums in C but not in C++, 
"arithmetic" doesn't include complex types in C++ (although it does by 
extension in Clang), etc.  I think for operands you probably want arithmetic 
types in the real domain (which in Clang is `isRealType()`).  However, you'll 
want to use a narrower term for the restriction on element types because Clang 
does support fixed-point types, but you probably don't want to support matrices 
of them quite yet (and you may not want to allow matrices of bools, either).

Also, your description of the scalar conversions no longer promotes them to 
matrix type.



Comment at: clang/docs/MatrixTypes.rst:123
+  M2 are of arithmetic type, they are broadcast to matrices here. — end note ]
+* The matrix types of M1 and M2 shall have the same number of rows and columns.
+* The result is equivalent to Res in the following where col is the number of

They also have to have the same element types, right?  So they have to be the 
same types?



Comment at: clang/docs/MatrixTypes.rst:138
+* The type of ``M1`` shall have the same number of columns as the type of 
``M2`` has
+  rows.
+* The resulting type, ``MTy``, is the result of applying the usual arithmetic

Same point about element types.



Comment at: clang/docs/MatrixTypes.rst:141
+  conversions to ``M1`` and ``M2``, but with the same number of rows as M1’s 
matrix
+  type and the same number of columns as M2’s matrix type.
+* The result is equivalent to ``Res`` in the following where ``EltTy`` is the

The easier way to put this now is that it's a matrix type whose element type is 
the common element type, but with the number of rows of `M1` and the number of 
columns of `M2`.



Comment at: clang/docs/MatrixTypes.rst:152
+  EltTy Elt = 0;
+  for (int K = 0; K < inner; ++K) {
+Elt += M1[R][K] * M2[K][C];

`inner` is not defined.



Comment at: clang/docs/MatrixTypes.rst:164
+Clang option to override this behavior and allow contraction of those
+operations (e.g. *-ffp-contract=matrix*).
+

This is about rounding, not rounding "errors".

The definition of matrix multiply you've written it above would actually permit 
an FMA under C's default rules.

More broadly, I think you need to define how the FP contraction and environment 
rules affect matrix arithmetic expressions.  If FP contraction is enabled, can 
`S * M1 + M2` perform elementwise FMAs?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/docs/MatrixSupport.rst:39
+
+Future Work: Initialization syntax.
+

rjmccall wrote:
> Maybe break the TODOs here into their own sections, which would come much 
> later.
Done, I've moved the TODOs to a TODO section just after the builtins section.



Comment at: clang/docs/MatrixSupport.rst:70
+between the original and resulting type, the program is ill-formed. Otherwise
+the resulting value is as follows:
+

rjmccall wrote:
> I don't think you need to list out the kinds of promotion and conversion 
> here, and it doesn't make sense to define the "resulting type" this way when 
> it's really a parameter.  I'd just say:
> 
> > A value of matrix type can be converted to another matrix type if the 
> > number of rows and columns are the size and the value's elements can be 
> > converted to the element type of the result type.  The result is a matrix 
> > where each element is the converted corresponding element.
> 
> > A value of non-matrix type can be converted to a matrix type if it can be 
> > converted to the element type of the matrix.  The result is a matrix where 
> > all elements are the converted original value.
I've kept the first paragraph (including the exclusion of assignment) and 
replaced the second with your suggestion.



Comment at: clang/docs/MatrixSupport.rst:129
+For ``BIN_OP`` in ``+``, ``-``, ``*`` given the expression ``M1 BIN_OP M2`` 
where, for
+``*``, one of M1 or M2 is of arithmetic type:
+

rjmccall wrote:
> Here I think you can say "where at least one of M1 or M2 is of matrix type 
> and, for `*`, the other is of arithmetic type".
> 
> I think you'll need to separately describe the restrictions on `+=`, `-=`, 
> and `*=`, but you should be able to say that the semantics are as if for the 
> expansion.
I added the following at the end of the section

> For the ``+=``, ``-=`` and ``*=`` operators the semantics match their 
> expanded variants.




Comment at: clang/docs/MatrixSupport.rst:211
+
+``M __builtin_matrix_column_load(T *ptr, int row, int col, int stride)``
+

rjmccall wrote:
> This name sounds like it's loading a column, when I think you're saying that 
> the memory has to be in column-major order.
> 
> I would call `stride` something like `columnStride` to make it clear that 
> it's the stride between columns, as opposed to a stride between the elements 
> within a column, which is also something that's theoretically interesting.
> 
> Should `stride` be an optional argument to make it easier to write the (I 
> expect) common case where the matrix is dense?
> This name sounds like it's loading a column, when I think you're saying that 
> the memory has to be in column-major order.

Yes that is correct. Maybe __builtin_matrix_columnwise_load would be slightly 
better?

> Should stride be an optional argument to make it easier to write the (I 
> expect) common case where the matrix is dense?
Yes that would be very convenient, especially now that casting between element 
wise pointers and matrixes is not allowed. I've added a sentence to the remarks 
for both the load and store builtins.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 257115.
fhahn marked 10 inline comments as done.
fhahn added a comment.

Address latest comments, thanks again!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,319 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size matrices as language values and perform arithmetic on them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *lement ype*. The
+internal layout, overall size and alignment are implementation-defined.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be an unqualified integer or floating-point type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the size and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of non-matrix type can be converted to a matrix type if it can be
+converted to the element type of the matrix. The result is a matrix where
+all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row and column in
+the matrix.
+
+Programs containing a single subscript expression into a matrix are ill-formed.
+
+**Note**: We considered 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 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Reading through the rest of the spec.




Comment at: clang/docs/LanguageExtensions.rst:500
+Clang provides a matrix extension, which is currently being implemented. See
+:ref:`matrixsupport` for more details.
+

rjmccall wrote:
> This should include just a bit more detail about the extension.  I would 
> suggest:
> 
> > Clang supports matrix types as an experimental extension.  See 
> > :`ref`matrices` for more details.
If we're calling the extension "matrix types", that should be reflected in this 
section name and in the file name.



Comment at: clang/docs/MatrixSupport.rst:28
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+

No need to italicize "element type" the second time.

The italics introduce a term, so consider italicizing "rows" and "columns" as 
well in the first sentence.



Comment at: clang/docs/MatrixSupport.rst:39
+
+Future Work: Initialization syntax.
+

Maybe break the TODOs here into their own sections, which would come much later.



Comment at: clang/docs/MatrixSupport.rst:70
+between the original and resulting type, the program is ill-formed. Otherwise
+the resulting value is as follows:
+

I don't think you need to list out the kinds of promotion and conversion here, 
and it doesn't make sense to define the "resulting type" this way when it's 
really a parameter.  I'd just say:

> A value of matrix type can be converted to another matrix type if the number 
> of rows and columns are the size and the value's elements can be converted to 
> the element type of the result type.  The result is a matrix where each 
> element is the converted corresponding element.

> A value of non-matrix type can be converted to a matrix type if it can be 
> converted to the element type of the matrix.  The result is a matrix where 
> all elements are the converted original value.



Comment at: clang/docs/MatrixSupport.rst:126
+The operands of ``+``, ``-`` and ``*`` shall have either matrix type, 
arithmetic or
+unscoped enumeration type. At least one of the operands shall be of matrix 
type.
+

I don't think this paragraph adds anything, and the restriction is kindof weird 
— it's just a restriction on when to consider applying these rules, rather than 
a restriction with absolute significance.

Also, "arithmetic type" includes unscoped enumeration types in both C and C++.



Comment at: clang/docs/MatrixSupport.rst:129
+For ``BIN_OP`` in ``+``, ``-``, ``*`` given the expression ``M1 BIN_OP M2`` 
where, for
+``*``, one of M1 or M2 is of arithmetic type:
+

Here I think you can say "where at least one of M1 or M2 is of matrix type and, 
for `*`, the other is of arithmetic type".

I think you'll need to separately describe the restrictions on `+=`, `-=`, and 
`*=`, but you should be able to say that the semantics are as if for the 
expansion.



Comment at: clang/docs/MatrixSupport.rst:176
+
+Matrix Type builtin Operations
+--

"builtin" should be capitalized here.



Comment at: clang/docs/MatrixSupport.rst:211
+
+``M __builtin_matrix_column_load(T *ptr, int row, int col, int stride)``
+

This name sounds like it's loading a column, when I think you're saying that 
the memory has to be in column-major order.

I would call `stride` something like `columnStride` to make it clear that it's 
the stride between columns, as opposed to a stride between the elements within 
a column, which is also something that's theoretically interesting.

Should `stride` be an optional argument to make it easier to write the (I 
expect) common case where the matrix is dense?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/docs/MatrixSupport.rst:3
+Matrix Support
+==
+

rjmccall wrote:
> This extension should be called something like "Matrices" or "Matrix Types".  
> The "X Support" name makes it sound like it's a support layer for some 
> external technology.
I changed it to "Matrix Types"



Comment at: clang/docs/MatrixSupport.rst:30
+directly. An *attribute-argument-clause* must be present and it shall have the
+form:
+

rjmccall wrote:
> You can assume the existence of a hypothetical external language 
> specification for GNU attribute syntax, so these starting paragraphs whittle 
> down to:
> 
> > Matrix types can be declared by adding the `matrix_type` attribute to the 
> > declaration of a `typedef` (or a C++ alias declaration).  The underlying 
> > type of the `typedef` must be an unqualified integer or floating-point 
> > type.  The attribute takes two arguments, both of which must be integer 
> > constant expressions that evaluate to a value greater than zero.  The first 
> > specifies the number of rows, and the second specifies the number of 
> > columns.  The underlying type of the `typedef` becomes a matrix type with 
> > the given dimensions and an element type of the former underlying type.
> 
> The paragraph about redeclarations is good.
Thanks, that helps to simplify this section a lot.



Comment at: clang/docs/MatrixSupport.rst:48
+Matrix Type
+---
+

rjmccall wrote:
> I would put this first before getting into the spelling.  You can also put 
> the stuff about implementation limits on dimensions in here.
Sounds good! Moved.



Comment at: clang/docs/MatrixSupport.rst:57
+
+A matrix type is a *scalar type* and its alignment is implementation defined.
+

rjmccall wrote:
> These are both important to include, but they're unrelated and shouldn't be 
> in the same sentence.
I moved the `scalar type` bit to the first sentence and move the part about the 
alignment to a separate sentence stating that the layout overall size and 
alignment are implementation defined.



Comment at: clang/docs/MatrixSupport.rst:64
+
+TODO: Specify how matrix values are passed to functions.
+

rjmccall wrote:
> That doesn't belong in a language specification, but you could reasonably add 
> a non-normative section at the end about the decisions that Clang currently 
> makes for things like size, alignment, internal layout, and argument/result 
> conventions.
I've added a new  `Decisions for the Implementation in Clang` section



Comment at: clang/docs/MatrixSupport.rst:110
+the matrix. The expression E1 is sequenced before E2 and E3. The expressions
+E2 and E3 are unsequenced.
+

rjmccall wrote:
> I'd put all this like:
> 
> > An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type 
> > ``cv M``, is a matrix element access expression.  Let ``T`` be the element 
> > type of ``M``, and let ``R`` and ``C`` be the number of rows and columns in 
> > ``M`` respectively.  The index expressions shall have integral or unscoped 
> > enumeration type and shall not be uses of the comma operator unless 
> > parenthesized.  The first index expression shall evaluate to a non-negative 
> > value less than ``R``, and the second index expression shall evaluate to a 
> > non-negative value less than ``C``, or else the expression has undefined 
> > behavior.  If ``E1`` is a prvalue, the result is a prvalue with type ``T`` 
> > and is the value of the element at the given row and column in the matrix.  
> > Otherwise, the result is a glvalue with type ``cv T`` and with the same 
> > value category as ``E1`` which refers to the element at the given row and 
> > column in the matrix.
Updated, thanks.



Comment at: clang/docs/MatrixSupport.rst:118
+builtins to extract rows and columns from a matrix. This makes the operations
+more explicit.
+

rjmccall wrote:
> You should add a normative paragraph saying that a program is ill-formed if 
> it insufficiently subscripts into a matrix.
I added the following
> Programs containing a single subscript expression into a matrix are 
> ill-formed.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 257025.
fhahn marked 15 inline comments as done.
fhahn added a comment.

Address @rjmccall comments.

In D76612#1975719 , @rjmccall wrote:

> Scanned through the first bit.


Thanks a lot! I hope I managed to address the comments adequately.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixSupport.rst

Index: clang/docs/MatrixSupport.rst
===
--- /dev/null
+++ clang/docs/MatrixSupport.rst
@@ -0,0 +1,312 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixsupport:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size matrices as language values and perform arithmetic on them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+.. _matrixsupport-draftspec:
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of rows, and a constant number of columns. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+TODO: Does it make sense to allow M::element_type, M::rows, and M::columns
+where M is a matrix type? We don’t support this anywhere else, but it’s
+convenient. The alternative is using template deduction to extract this
+information. Also add spelling for C.
+
+Future Work: Initialization syntax.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be an unqualified integer or floating-point type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+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.
+
+For integral promotions, floating-point promotion, integral conversions,
+floating-point conversions, and floating-integral conversions: apply the rules
+to the underlying type of the matrix type. The resulting type is a matrix type
+with that underlying element type. If the number of rows or columns differ
+between the original and resulting type, the program is ill-formed. Otherwise
+the resulting value is as follows:
+
+* If the original value was of matrix type, each element is converted element
+  by element.
+* If the original value was not of matrix type, each element takes the value of
+  the original value.
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Scanned through the first bit.




Comment at: clang/docs/LanguageExtensions.rst:500
+Clang provides a matrix extension, which is currently being implemented. See
+:ref:`matrixsupport` for more details.
+

This should include just a bit more detail about the extension.  I would 
suggest:

> Clang supports matrix types as an experimental extension.  See 
> :`ref`matrices` for more details.



Comment at: clang/docs/MatrixSupport.rst:3
+Matrix Support
+==
+

This extension should be called something like "Matrices" or "Matrix Types".  
The "X Support" name makes it sound like it's a support layer for some external 
technology.



Comment at: clang/docs/MatrixSupport.rst:12
+matrix math on the C/C++ level. The draft specification can be found
+:ref:`below `.
+

1. "Clang provides a C/C++ language extension that allows users to directly 
express fixed-size matrices as language values and perform arithmetic on them."

2. This document *is* the specification, there's nothing to cross-reference it.



Comment at: clang/docs/MatrixSupport.rst:14
+
+Note that the implementation is currently in progress.
+

"This feature is currently experimental, and both its design and its 
implementation are in flux."



Comment at: clang/docs/MatrixSupport.rst:30
+directly. An *attribute-argument-clause* must be present and it shall have the
+form:
+

You can assume the existence of a hypothetical external language specification 
for GNU attribute syntax, so these starting paragraphs whittle down to:

> Matrix types can be declared by adding the `matrix_type` attribute to the 
> declaration of a `typedef` (or a C++ alias declaration).  The underlying type 
> of the `typedef` must be an unqualified integer or floating-point type.  The 
> attribute takes two arguments, both of which must be integer constant 
> expressions that evaluate to a value greater than zero.  The first specifies 
> the number of rows, and the second specifies the number of columns.  The 
> underlying type of the `typedef` becomes a matrix type with the given 
> dimensions and an element type of the former underlying type.

The paragraph about redeclarations is good.



Comment at: clang/docs/MatrixSupport.rst:48
+Matrix Type
+---
+

I would put this first before getting into the spelling.  You can also put the 
stuff about implementation limits on dimensions in here.



Comment at: clang/docs/MatrixSupport.rst:55
+padding in a way compatible with an array of at least that many elements of the
+underlying *element type*.
+

Do you actually want to guarantee this layout in the language specification?  I 
would just say that a matrix includes storage for `rows * columns` elements but 
that the interior layout and overall size and alignment are 
implementation-defined.



Comment at: clang/docs/MatrixSupport.rst:57
+
+A matrix type is a *scalar type* and its alignment is implementation defined.
+

These are both important to include, but they're unrelated and shouldn't be in 
the same sentence.



Comment at: clang/docs/MatrixSupport.rst:64
+
+TODO: Specify how matrix values are passed to functions.
+

That doesn't belong in a language specification, but you could reasonably add a 
non-normative section at the end about the decisions that Clang currently makes 
for things like size, alignment, internal layout, and argument/result 
conventions.



Comment at: clang/docs/MatrixSupport.rst:106
+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

It would be better to say explicitly that "The index expressions shall..."



Comment at: clang/docs/MatrixSupport.rst:110
+the matrix. The expression E1 is sequenced before E2 and E3. The expressions
+E2 and E3 are unsequenced.
+

I'd put all this like:

> An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv 
> M``, is a matrix element access expression.  Let ``T`` be the element type of 
> ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M`` 
> respectively.  The index expressions shall have integral or unscoped 
> enumeration type and shall not be uses of the comma operator unless 
> parenthesized.  The first index expression shall evaluate to a non-negative 
> value less than ``R``, and the second index expression shall evaluate to a 
> non-negative value less than ``C``, or else the expression has undefined 
> behavior.  If ``E1`` is a prvalue, the result is a prvalue with type ``T`` 
> and is the value of 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn marked an inline comment as done.
fhahn added inline comments.



Comment at: clang/docs/MatrixSupport.rst:254
+
+Example
+===

SjoerdMeijer wrote:
> Hi Florian, just reading this for the first time, this is cool stuff, and 
> just a drive-by comment:
> 
> this section, Example, looks like a good candidate to be moved to the 
> "Matrixes" section in 
> clang/docs/LanguageExtensions.rst. This is Clang/LLVM specific, may not be 
> that relevant for a language draft spec? But anyway, it may also be some of 
> the user-facing examples missing in the language extension doc.
Ah yes, it seems like the LLVM IR lowering does not fit either here or in 
LanguageExtensions. It might be good to move the example to LanguageExtnesions 
though.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/docs/MatrixSupport.rst:254
+
+Example
+===

Hi Florian, just reading this for the first time, this is cool stuff, and just 
a drive-by comment:

this section, Example, looks like a good candidate to be moved to the 
"Matrixes" section in 
clang/docs/LanguageExtensions.rst. This is Clang/LLVM specific, may not be that 
relevant for a language draft spec? But anyway, it may also be some of the 
user-facing examples missing in the language extension doc.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 255341.
fhahn added a comment.

Update standard conversion wording as suggested by @rjmccall


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixSupport.rst

Index: clang/docs/MatrixSupport.rst
===
--- /dev/null
+++ clang/docs/MatrixSupport.rst
@@ -0,0 +1,305 @@
+==
+Matrix Support
+==
+
+.. contents::
+   :local:
+
+.. _matrixsupport:
+
+Clang provides a language extension that allows users to express high-level
+matrix math on the C/C++ level. The draft specification can be found
+:ref:`below `.
+
+Note that the implementation is currently in progress.
+
+.. _matrixsupport-draftspec:
+
+Draft Specification
+===
+
+Matrix Type Attribute
+-
+
+The *attribute-token* ``matrix_type`` is used to declare a matrix type. It shall
+appear at most once in each *attribute-list*. The attribute shall only appertain
+to a *typedef-name* of a typedef of a non-volatile type that is a *signed
+integer type*, an *unsigned integer type*, or a *floating-point type*. The
+element type must be unqualified and qualifiers are applied to the matrix type
+directly. An *attribute-argument-clause* must be present and it shall have the
+form:
+
+``(constant-expression, constant-expression)``
+
+Both *constant-expressions* shall be a positive non-zero integral constant
+expressions. The maximum of the product of the constants is implementation
+defined. If that implementation defined limit is exceeded, the program is
+ill-formed.
+
+An *attribute* of the form ``matrix_type(R, C)`` forms a matrix type with an
+element type of the cv-qualified type the attribute appertains to and *R* rows
+and *C* columns.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Matrix Type
+---
+
+A matrix type has an underlying *element type*, a constant number of rows, and
+a constant number of columns. Matrix types with the same element type, rows,
+and columns are the same type. A value of a matrix type contains ``rows *
+columns`` values of the *element type* laid out in column-major order without
+padding in a way compatible with an array of at least that many elements of the
+underlying *element type*.
+
+A matrix type is a *scalar type* and its alignment is implementation defined.
+
+TODO: Does it make sense to allow M::element_type, M::rows, and M::columns
+where M is a matrix type? We don’t support this anywhere else, but it’s
+convenient. The alternative is using template deduction to extract this
+information. Also add spelling for C.
+
+TODO: Specify how matrix values are passed to functions.
+
+Future Work: Initialization syntax.
+
+Standard Conversions
+
+
+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.
+
+For integral promotions, floating-point promotion, integral conversions,
+floating-point conversions, and floating-integral conversions: apply the rules
+to the underlying type of the matrix type. The resulting type is a matrix type
+with that underlying element type. If the number of rows or columns differ
+between the original and resulting type, the program is ill-formed. Otherwise
+the resulting value is as follows:
+
+* If the original value was of matrix type, each element is converted element
+  by element.
+* If the original value was not of matrix type, each element takes the value of
+  the original value.
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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.
+
+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

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 254861.
fhahn added a comment.

Specify that standard conversion rules do not apply to assignments for matrix 
types.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixSupport.rst

Index: clang/docs/MatrixSupport.rst
===
--- /dev/null
+++ clang/docs/MatrixSupport.rst
@@ -0,0 +1,303 @@
+==
+Matrix Support
+==
+
+.. contents::
+   :local:
+
+.. _matrixsupport:
+
+Clang provides a language extension that allows users to express high-level
+matrix math on the C/C++ level. The draft specification can be found
+:ref:`below `.
+
+Note that the implementation is currently in progress.
+
+.. _matrixsupport-draftspec:
+
+Draft Specification
+===
+
+Matrix Type Attribute
+-
+
+The *attribute-token* ``matrix_type`` is used to declare a matrix type. It shall
+appear at most once in each *attribute-list*. The attribute shall only appertain
+to a *typedef-name* of a typedef of a non-volatile type that is a *signed
+integer type*, an *unsigned integer type*, or a *floating-point type*. The
+element type must be unqualified and qualifiers are applied to the matrix type
+directly. An *attribute-argument-clause* must be present and it shall have the
+form:
+
+``(constant-expression, constant-expression)``
+
+Both *constant-expressions* shall be a positive non-zero integral constant
+expressions. The maximum of the product of the constants is implementation
+defined. If that implementation defined limit is exceeded, the program is
+ill-formed.
+
+An *attribute* of the form ``matrix_type(R, C)`` forms a matrix type with an
+element type of the cv-qualified type the attribute appertains to and *R* rows
+and *C* columns.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Matrix Type
+---
+
+A matrix type has an underlying *element type*, a constant number of rows, and
+a constant number of columns. Matrix types with the same element type, rows,
+and columns are the same type. A value of a matrix type contains ``rows *
+columns`` values of the *element type* laid out in column-major order without
+padding in a way compatible with an array of at least that many elements of the
+underlying *element type*.
+
+A matrix type is a *scalar type* and its alignment is implementation defined.
+
+TODO: Does it make sense to allow M::element_type, M::rows, and M::columns
+where M is a matrix type? We don’t support this anywhere else, but it’s
+convenient. The alternative is using template deduction to extract this
+information. Also add spelling for C.
+
+TODO: Specify how matrix values are passed to functions.
+
+Future Work: Initialization syntax.
+
+Standard Conversions
+
+
+The standard conversions are extended as follows, with the exception that for
+matrix types, standard conversions are not permissible for assignments.
+
+For integral promotions, floating-point promotion, integral conversions,
+floating-point conversions, and floating-integral conversions: apply the rules
+to the underlying type of the matrix type. The resulting type is a matrix type
+with that underlying element type. If the number of rows or columns differ
+between the original and resulting type, the program is ill-formed. Otherwise
+the resulting value is as follows:
+
+* If the original value was of matrix type, each element is converted element
+  by element.
+* If the original value was not of matrix type, each element takes the value of
+  the original value.
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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.
+
+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 considered providing an 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 254505.
fhahn added a comment.

Update arithmetic conversion rules after recent discussion on cfe-dev.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixSupport.rst

Index: clang/docs/MatrixSupport.rst
===
--- /dev/null
+++ clang/docs/MatrixSupport.rst
@@ -0,0 +1,301 @@
+==
+Matrix Support
+==
+
+.. contents::
+   :local:
+
+.. _matrixsupport:
+
+Clang provides a language extension that allows users to express high-level
+matrix math on the C/C++ level. The draft specification can be found :ref:`below `.
+
+Note that the implementation is currently in progress.
+
+.. _matrixsupport-draftspec:
+
+Draft Specification
+===
+
+Matrix Type Attribute
+-
+
+The *attribute-token* ``matrix_type`` is used to declare a matrix type. It shall
+appear at most once in each *attribute-list*. The attribute shall only appertain
+to a *typedef-name* of a typedef of a non-volatile type that is a *signed 
+integer type*, an *unsigned integer type*, or a *floating-point type*. The
+element type must be unqualified and qualifiers are applied to the matrix type
+directly. An *attribute-argument-clause* must be present and it shall have the
+form:
+
+``(constant-expression, constant-expression)``
+
+Both *constant-expressions* shall be a positive non-zero integral constant
+expressions. The maximum of the product of the constants is implementation
+defined. If that implementation defined limit is exceeded, the program is
+ill-formed.
+
+An *attribute* of the form ``matrix_type(R, C)`` forms a matrix type with an
+element type of the cv-qualified type the attribute appertains to and *R* rows
+and *C* columns.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Matrix Type
+---
+
+A matrix type has an underlying *element type*, a constant number of rows, and
+a constant number of columns. Matrix types with the same element type, rows,
+and columns are the same type. A value of a matrix type contains ``rows *
+columns`` values of the *element type* laid out in column-major order without
+padding in a way compatible with an array of at least that many elements of the
+underlying *element type*.
+
+A matrix type is a *scalar type* and its alignment is implementation defined.
+
+TODO: Does it make sense to allow M::element_type, M::rows, and M::columns
+where M is a matrix type? We don’t support this anywhere else, but it’s
+convenient. The alternative is using template deduction to extract this
+information. Also add spelling for C.
+
+TODO: Specify how matrix values are passed to functions.
+
+Future Work: Initialization syntax.
+
+Standard Conversions
+
+
+The standard conversions are extended as follows.
+
+For integral promotions, floating-point promotion, integral conversions,
+floating-point conversions, and floating-integral conversions: apply the rules
+to the underlying type of the matrix type. The resulting type is a matrix type
+with that underlying element type. If the number of rows or columns differ
+between the original and resulting type, the program is ill-formed. Otherwise
+the resulting value is as follows:
+
+* If the original value was of matrix type, each element is converted element
+  by element.
+* If the original value was not of matrix type, each element takes the value of
+  the original value.
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* 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.
+
+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 considered providing an expression of the form
+``postfix-expression [expression]`` to access columns of a matrix. We think
+that such an 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 252995.
fhahn added a comment.

Update according to comments on cfe-dev.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76612/new/

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixSupport.rst

Index: clang/docs/MatrixSupport.rst
===
--- /dev/null
+++ clang/docs/MatrixSupport.rst
@@ -0,0 +1,300 @@
+==
+Matrix Support
+==
+
+.. contents::
+   :local:
+
+.. _matrixsupport:
+
+Clang provides a language extension that allows users to express high-level
+matrix math on the C/C++ level. The draft specification can be found :ref:`below `.
+
+Note that the implementation is currently in progress.
+
+.. _matrixsupport-draftspec:
+
+Draft Specification
+===
+
+Matrix Type Attribute
+-
+
+The *attribute-token* ``matrix_type`` is used to declare a matrix type. It shall
+appear at most once in each *attribute-list*. The attribute shall only appertain
+to a *typedef-name* of a typedef of a non-volatile type that is a *signed 
+integer type*, an *unsigned integer type*, or a *floating-point type*. The
+element type must be unqualified and qualifiers are applied to the matrix type
+directly. An *attribute-argument-clause* must be present and it shall have the
+form:
+
+``(constant-expression, constant-expression)``
+
+Both *constant-expressions* shall be a positive non-zero integral constant
+expressions. The maximum of the product of the constants is implementation
+defined. If that implementation defined limit is exceeded, the program is
+ill-formed.
+
+An *attribute* of the form ``matrix_type(R, C)`` forms a matrix type with an
+element type of the cv-qualified type the attribute appertains to and *R* rows
+and *C* columns.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Matrix Type
+---
+
+A matrix type has an underlying *element type*, a constant number of rows, and
+a constant number of columns. Matrix types with the same element type, rows,
+and columns are the same type. A value of a matrix type contains ``rows *
+columns`` values of the *element type* laid out in column-major order without
+padding in a way compatible with an array of at least that many elements of the
+underlying *element type*.
+
+A matrix type is a *scalar type* and its alignment is implementation defined.
+
+TODO: Does it make sense to allow M::element_type, M::rows, and M::columns
+where M is a matrix type? We don’t support this anywhere else, but it’s
+convenient. The alternative is using template deduction to extract this
+information. Also add spelling for C.
+
+TODO: Specify how matrix values are passed to functions.
+
+Future Work: Initialization syntax.
+
+Standard Conversions
+
+
+The standard conversions are extended as follows.
+
+For integral promotions, floating-point promotion, integral conversions,
+floating-point conversions, and floating-integral conversions: apply the rules
+to the underlying type of the matrix type. The resulting type is a matrix type
+with that underlying element type. If the number of rows or columns differ
+between the original and resulting type, the program is ill-formed. Otherwise
+the resulting value is as follows:
+
+* If the original value was of matrix type, each element is converted element
+  by element.
+* If the original value was not of matrix type, each element takes the value of
+  the original value.
+
+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.
+
+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 considered 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 

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

[Florian Hahn via Phabricator via cfe-commits]

fhahn created this revision.
fhahn added reviewers: rsmith, anemet, Bigcheese, dexonsmith.
Herald added a subscriber: tschuett.
Herald added a project: clang.

This patch documents the planned matrix support in Clang, based on the
draft specification discussed on cfe-dev in the 'Matrix Support in
Clang' thread.

Latest draft spec sent to cfe-dev: 
http://lists.llvm.org/pipermail/cfe-dev/2020-February/064742.html
Discussion thread January: 
http://lists.llvm.org/pipermail/cfe-dev/2020-January/064206.html
Discussion thread March: 
http://lists.llvm.org/pipermail/cfe-dev/2020-March/064834.html


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixSupport.rst

Index: clang/docs/MatrixSupport.rst
===
--- /dev/null
+++ clang/docs/MatrixSupport.rst
@@ -0,0 +1,301 @@
+==
+Matrix Support
+==
+
+.. contents::
+   :local:
+
+.. _matrixsupport:
+
+Clang provides a language extension that allows users to express high-level
+matrix math on the C/C++ level. The draft specification can be found :ref:`below `.
+
+Note that the implementation is currently in progress.
+
+.. _matrixsupport-draftspec:
+
+Draft Specification
+===
+
+Matrix Type Attribute
+-
+
+The *attribute-token* ``matrix_type`` is used to declare a matrix type. It shall
+appear at most once in each *attribute-list*. The attribute shall only appertain
+to a *typedef-name* of a typedef of a non-volatile type that is a *signed 
+integer type*, an *unsigned integer type*, or a *floating-point type*. An
+*attribute-argument-clause* must be present and it shall have the form:
+
+``(constant-expression, constant-expression)``
+
+Both *constant-expressions* shall be a positive non-zero integral constant
+expressions. The maximum of the product of the constants is implementation
+defined. If that implementation defined limit is exceeded, the program is
+ill-formed.
+
+An *attribute* of the form ``matrix_type(R, C)`` forms a matrix type with an
+element type of the cv-qualified type the attribute appertains to and *R* rows
+and *C* columns.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Matrix Type
+---
+
+A matrix type has an underlying *element type*, a constant number of rows, and
+a constant number of columns. Matrix types with the same element type, rows,
+and columns are the same type. A value of a matrix type contains ``rows *
+columns`` values of the *element type* laid out in column-major order without
+padding in a way compatible with an array of at least that many elements of the
+underlying *element type*.
+
+A matrix type is a *scalar type* with the same alignment as its underlying
+element type, but objects of matrix type are not usable in constant
+expressions.
+
+TODO: Allow reinterpret_cast from pointer to element type. Make aliasing work.
+
+TODO: Does it make sense to allow M::element_type, M::rows, and M::columns
+where M is a matrix type? We don’t support this anywhere else, but it’s
+convenient. The alternative is using template deduction to extract this
+information.
+
+Future Work: Initialization syntax.
+
+Future Work: Conversions between matrix types with const qualified and
+unqualified element types.
+
+Standard Conversions
+
+
+The standard conversions are extended as follows.
+
+For integral promotions, floating-point promotion, integral conversions,
+floating-point conversions, and floating-integral conversions: apply the rules
+to the underlying type of the matrix type. The resulting type is a matrix type
+with that underlying element type. The resulting value is as follows:
+
+* If the original value was of matrix type, each element is converted element
+  by element.
+* If the original value was not of matrix type, each element takes the value of
+  the original value.
+
+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.
+
+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