cofibrant wrote: I've thought about this some more and I'll summarise my understanding. AFAIU, there are two separate concerns here: 1. The layout of matrices types in memory; 2. The layout used by LLVM when lowering matrix intrinsics.
As far as the matrix intrinsics are concerned, at least as they are exposed in the language reference, 2. is an implementation detail and is orthogonal from 1. As an example, say I have a matrix `A` in memory in a column major layout and I call `@llvm.matrix.column.major.load` on it. With `-matrix-default-layout=row-major`, the lowering pass will generate sequence of strided loads fetching the _rows_ of `A`. All subsequent operations will be row major until I call `@llvm.matrix.column.major.store`, at which point the a series of strides stores will be emitted, writing back the rows of whatever matrix I'm looking at now in a column major format. To support row major memory layouts, we need to implement `@llvm.matrix.row.major.*` intrinsics and instruct the `clang` frontend to use these. In situations where all matrix operations are acting on row major matrices, there is then a _performance_ reason to switch the default matrix layout to row major. https://github.com/llvm/llvm-project/pull/167628 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
