Hi Jeevitha,
On 26/08/26 11:20 am, jeevitha wrote:
diff --git a/gcc/testsuite/gcc.target/powerpc/mma-double-test.c
b/gcc/testsuite/gcc.target/powerpc/mma-double-test.c
index 254af7f8f79..3ef4da5281f 100644
--- a/gcc/testsuite/gcc.target/powerpc/mma-double-test.c
+++ b/gcc/testsuite/gcc.target/powerpc/mma-double-test.c
@@ -52,7 +52,13 @@ MMA (int m, int n, int k, double *A, double *B, double *C)
vec_t *rowA = (vec_t *) & AO[i * 16];
__vector_pair rowB;
vec_t *rb = (vec_t *) & BO[i * 4];
+/* The register order of __builtin_mma_assemble_pair is endian
+ dependent, so the halves must be swapped on big endian. */
+#ifdef __BIG_ENDIAN__
+ __builtin_mma_assemble_pair (&rowB, rb[0], rb[1]);
+#else
__builtin_mma_assemble_pair (&rowB, rb[1], rb[0]);
+#endif
__builtin_mma_xvf64gerpp (&acc0, rowB, rowA[0]);
__builtin_mma_xvf64gerpp (&acc1, rowB, rowA[1]);
__builtin_mma_xvf64gerpp (&acc2, rowB, rowA[2]);
I see PR96236, which handles __builtin_mma_disassemble_acc, so disassemble is
endian-independent. If __builtin_mma_assemble_pair is endian-dependent,
could you clarify the reason for this difference?
I also see that in rs6000-builtins.cc we already swap the operands for
__builtin_mma_assemble_pair on little-endian targets:
if (fcode == RS6000_BIF_ASSEMBLE_PAIR_V_INTERNAL && !WORDS_BIG_ENDIAN)
std::swap (op[1], op[2]);
Can you please take a look at this?
Yeah nice catch ! I have posted my view (comment #1) on the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126866
I will post the same here too
I see that OpenBLAS does the following
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
#define __builtin_vsx_assemble_pair2(vp0, v0, v1)
__builtin_vsx_assemble_pair(vp0, v1, v0)
#else
#define __builtin_vsx_assemble_pair2(vp0, v0, v1)
__builtin_vsx_assemble_pair(vp0, v0, v1)
#endif
Link to the code above:
https://github.com/OpenMathLib/OpenBLAS/blob/632ef874379c16ca8646d9fa0f6c60449e47d960/kernel/power/gemm_common.c#L22
PR96236 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96236> handles the
little-endian memory ordering in the backend rs6000_gimple_fold_mma_builtin.
My opinion is that for any given function(builtins) the order of the parameters
must not depend on the Endianness, rather it should be handled by the compiler.
So which approach do I take here? If I change the behaviour, then software such
as OpenBLAS have to revert/comply to the new changes.
Thanks,
Manjunath S Matti.
