farzonl wrote: > I'm still struggling to understand the motivation for this change and the > broader program of changes you keep bringing up. As far as I understand, > there are three separate issues at play which we seem to be conflating: > > 1. How matrix types are exposed in the Clang front-end (e.g., whether an > initialiser list is treated as row / column major); > 2. How Clang lays out matrix types in memory; > 3. How LLVM lowers use of matrix builtins to vector instructions. > > In my opinion, it does not make much sense for a compiler flag to impact 1, > and it makes perfect sense for both 2 and 3 to vary independently of 1 under > the hood. If row major memory layout is important and a priority, work to > implement the corresponding LLVM intrinsics should come first. It seems very > premature to add to, e.g., the release notes that we're allowing users to > control matrix memory layouts when nothing in the compiler has changed to > actually support these.
@cofibrant Ok here is my plan for unblocking this pr: @fhahn mentioned: > I think you have to also prevent using builtin_column_major_load/store (or > preferably update LowerMatrixIntrinsics), because currently using them in > row-major mode causes a crash: https://clang.godbolt.org/z/1Gd41Gx7P I will add back the -mllvm flags and use the clang flag to enable or disable usage of `__builtin_matrix_column_major_load` and `__builtin_matrix_column_major_store` based on this flag. That at least will let this flag prevent a crash. - I'll hold off on any changes that impact initalizer lists. - Hopefully we can move forward with MatrixSubscriptExpr indexing changes though? - I'll move forward with clang-dxc driver changes that will let me map /Zpr and /Zpc to the equivalent column/row major order flag. https://github.com/llvm/llvm-project/pull/167628 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
