https://github.com/inbelic approved this pull request.
Noted from offline discussion: I was curious why this choice was taken over: 1. Defining a `llvm.matrix.mul_rowmajor` intrinsic to emit instead 2. Loading values to/storing values from a register/buffer in an orientation agnostic way Considering 1, I suggests this aligns more with how we interact with other llvm types, for instance `i32` and their (un)signed operations. However, it does not extend to the case when individual matrices can be specified as row/col major, we would then need to introduce transposes on them regardless. Considering 2, this might look something like adding a matrix transpose at each load/store of a (entire) row-major matrix into a resource. I do believe this would work out with individual row/component access. With that being said, `mul` and `transpose` are from a very limited set of operations that are scalarized on matrices in a non-elementwise way, so this might actually result in generating less instructions anyway, particularly when composed transposes are eliminated. This LGTM and it should be functionally equivalent to 1 or 2. https://github.com/llvm/llvm-project/pull/186898 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
