francisvm 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.
I tend to agree with all of this + what @fhahn said at first. `1.` could be solved with some kind of builtin that explicitly specifies the layout of the producer, and by the time everything reaches the matrix lowering pass in row-major form, things should be already working. https://github.com/llvm/llvm-project/pull/167628 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
