[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #33 from Jakub Jelinek --- .
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #32 from Jakub Jelinek --- https://gcc.gnu.org/g:eec8da328cf1f91db302ab4cee803e269e68ad33 commit r16-8584-geec8da328cf1f91db302ab4cee803e269e68ad33 Author: Surya Kumari Jangala Date: Sat Apr 11 12:19:45 2026 -0500 Revert "rs6000: Disassemble opaque modes using subregs to allow optimizations" This reverts commit 69a2c243dd2cf9f77150c0eb86dfbc0931876bc1 to resolve the issue reported in PR124804. Let's close this as fixed, if PowerPC maintainers want to resolve this differently for GCC 17, a new PR can be opened to track it. But I think if it uses SUBREGs, they need to use the documented behavior of SUBREG_BYTE preserving the memory ordering (which is saidly PDP-endian in little endian mode if I understand it right).
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #31 from Sam James --- Revert was done in r16-8584-geec8da328cf1f9. Shall we close this one now or do we want to retitle+reprioritise instead?
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #30 from Surya Kumari Jangala --- > In any case, changing that this late seems to be quite risky, so I think > reverting the patch might be best temporary solution for GCC 16. > Thoughts on that? I agree it is better to revert. Running some tests, will revert once done.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #29 from Jakub Jelinek --- Searching for REG_WORDS_BIG_ENDIAN, there are quite a few cases: ira.cc: if (REG_WORDS_BIG_ENDIAN) ira.cc: if (REG_WORDS_BIG_ENDIAN) ira-color.cc: if (REG_WORDS_BIG_ENDIAN) ira-color.cc: if (REG_WORDS_BIG_ENDIAN) ira-color.cc: if (REG_WORDS_BIG_ENDIAN) reload.cc: /* On a REG_WORDS_BIG_ENDIAN machine, point to the last register of a reload.cc: if (REG_WORDS_BIG_ENDIAN reload.cc: if (REG_WORDS_BIG_ENDIAN reload.cc: if (REG_WORDS_BIG_ENDIAN) rtlanal.cc: if (REG_WORDS_BIG_ENDIAN) rtlanal.cc: && WORDS_BIG_ENDIAN == REG_WORDS_BIG_ENDIAN rtlanal.cc: if (WORDS_BIG_ENDIAN != REG_WORDS_BIG_ENDIAN) so I'm afraid just tweaking rtlanal.cc wouldn't be enough. Guess if we want say introduce a target hook that will handle like REG_WORDS_BIG_ENDIAN only some modes or or mode/hard reg pairs and keep others as is it would need to change all those spots. And the question is if that can be changed, if there aren't say instructions to load a pair of general purpose registers (say for TImode loads/stores). In any case, changing that this late seems to be quite risky, so I think reverting the patch might be best temporary solution for GCC 16. Thoughts on that?
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2026-04-10 --- Comment #28 from Jakub Jelinek --- Note, if trying to change ppc64le behavior of subreg folding on OO/XOmode VSX regs, so that they match the memory ordering (i.e. that (subreg:V16QI (reg:OO N) 0) folds to (reg:V16QI N + 1) rather than (reg:V16QI N) and (subreg:V16QI (reg:OO N) 16) folds to (reg:V16QI N) rather than (reg:V16QI N + 1) etc.) is too complicated, perhaps yet another possibility would be to change the RTL representation of OOmode/XOmode memory loads and stores for little endian, so that it reflects the PDP-endian-ish behavior by permuting the 128-bit parts. Though not sure if LRA won't be upset by that and expects simple movoo or movxo to be really (set (regmem:OO) (regmem:OO)) rather than something that permutes the 128-bit parts.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #26 from Jakub Jelinek --- Unfortunately, right now there are no hooks that could choose to change simplify_subreg_regno behavior just for the subregs of OOmode/XOmode VSX registers and not other multireg regs, all the target can do is define REG_WORDS_BIG_ENDIAN perhaps differently from WORDS_BIG_ENDIAN so that the reg subregs could follow the memory order. Anyway, will defer this PR to somebody knowledgeable about PowerPC.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #27 from Surya Kumari Jangala --- I will look into a fix for this issue.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #24 from Jakub Jelinek --- The ISA 3.1 manual says: When Big-Endian byte ordering is employed, the contents of the octword in storage at address EA are placed into load_data in such an order that; – the contents of the byte in storage at address EA are placed into byte 0 of load_data, – the contents of the byte in storage at address EA+1 are placed into byte 1 of load_data, and so forth until – the contents of the byte in storage at address EA+31 are placed into byte 31 of load_data. When Little-Endian byte ordering is employed, the contents of the octword in storage at address EA are placed into load_data in such an order that; – the contents of the byte in storage at address EA are placed into byte 31 of load_data, – the contents of the byte in storage at address EA+1 are placed into byte 30 of load_data, and so forth until – the contents of the byte in storage at address EA+31 are placed into byte 0 of load_data. Bits 0-127 of load_data are placed into VSR[XTp]. Bits 128-255 of load_data is placed into VSR[XTp+1].
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
--- Comment #23 from Jakub Jelinek ---
In any case, (subreg:V16QI (reg:OO N) 0) folds to (reg:V16QI N) on little
endian and
(subreg:V16QI (reg:OO N) 16) folds to (reg:V16QI N+1), and
(subreg:V16QI (mem:OO X) 0) it folds to (mem:V16QI X) and
(subreg:V16QI (mem:OO X) 16) it folds to (mem:V16QI (plus X (const_int 16)).
And the behavior of lxvpx insn on little endian is clearly that it swaps the
doubleword order in the quadword:
(gdb) disas $pc,$pc+4
Dump of assembler code from 0x18fc to 0x1900:
=> 0x18fc : lxvpx vs44,r30,r2
End of assembler dump.
(gdb) stepi
0x1900 in BF16GEMV_T_MMA_8 ()
(gdb) x/32bx $r2+$r30
0x10020120 : 0xa90x3f0xb70x3f0xa70x3f0x94
0x3f
0x10020128 : 0x1a0x3f0x7a0x3f0x9e0x3f0x93
0x3f
0x10020130 : 0xad0x3f0x6a0x3f0x490x3f0x81
0x3f
0x10020138 : 0x410x3f0xba0x3f0x660x3f0xb0
0x3f
(gdb) p/x $vs44.v16_int8
$37 = {0xad, 0x3f, 0x6a, 0x3f, 0x49, 0x3f, 0x81, 0x3f, 0x41, 0x3f, 0xba, 0x3f,
0x66, 0x3f, 0xb0, 0x3f}
(gdb) p/x $vs45.v16_int8
$38 = {0xa9, 0x3f, 0xb7, 0x3f, 0xa7, 0x3f, 0x94, 0x3f, 0x1a, 0x3f, 0x7a, 0x3f,
0x9e, 0x3f, 0x93, 0x3f}
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #25 from Jakub Jelinek --- If we can't get this fixed very quickly, I'd think best would be to revert that commit and retry after GCC 16 is released.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #22 from Peter Bergner --- (In reply to Segher Boessenkool from comment #20) > (In reply to Jakub Jelinek from comment #18) > > So, I think there is some misunderstanding between the backend and RA on > > endianity, what actually > > (subreg:V16QI (reg:OO) 16) > > and > > (subreg:V16QI (reg:OO) 0) > > mean for ppc64le and what it means on > > (subreg:V16QI (mem:OO) 16) > > and > > (subreg:V16QI (mem:OO) 0) > > That sounds convincing! Is there any obvious wrong pattern? And/or can > you try this on correct-endian as well, see if it works there? When I left IBM in May, we did have a Power10 running in BE mode. I think this will take an IBMer to test that configuration.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #21 from Jakub Jelinek --- I'm afraid I don't have access to ppc64be anymore, especially not for power10. But I think CompileFarm has no longer the ppc64be machine it had (and it was power7 anyway). Anyway, for the RA it is clearly the case of having (expr_list:REG_EQUIV (mem:OO (plus:DI (reg/f:DI 253 [ _255 ]) (reg:DI 119 [ ivtmp.80 ])) [0 MEM[(__vector_pair *)_255 + ivtmp.80_3 * 1]+0 S32 A128]) and (subreg:V16QI (reg:OO 181 [ _110 ]) 0) use and turning that into folded (subreg:V16QI (mem:OO (...) 0). I think at least a SUBREG on MEM always means the location in memory order, so 0 is the first 16 bytes rather than second 16 bytes.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #20 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #18) > So, I think there is some misunderstanding between the backend and RA on > endianity, what actually > (subreg:V16QI (reg:OO) 16) > and > (subreg:V16QI (reg:OO) 0) > mean for ppc64le and what it means on > (subreg:V16QI (mem:OO) 16) > and > (subreg:V16QI (mem:OO) 0) That sounds convincing! Is there any obvious wrong pattern? And/or can you try this on correct-endian as well, see if it works there?
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #19 from Segher Boessenkool --- (In reply to Richard Biener from comment #15) > sched1 should have an effect on RA and thus post-reload combines/splits. Wow. Yes. sched2 overrides everything, sched1 is more provisional, but in the end sched1 matters more for eventual code quality!
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
--- Comment #18 from Jakub Jelinek ---
So, I think it is clear what's wrong. In the no scheduling case, we have (insn
66 + 86 + 90):
lxvpx 44,30,2
...
xvbf16ger2pp 5,45,49
...
xvbf16ger2pp 5,44,48
which is correct, lxvpx loads a __vector_pair from the correct address to
$vs44/$vs45:
(gdb) x/4gx $r2+$r30
0x10020120 : 0x3f943fa73fb73fa9 0x3f933f9e3f7a3f1a
0x10020130 : 0x3f813f493f6a3fad 0x3fb03f663fba3f41
(gdb) stepi
0x1900 in BF16GEMV_T_MMA_8 ()
(gdb) p/x $vs44
$33 = {float128 = 0x3fb03f663fba3f413f813f493f6a3fad, uint128 =
0x3fb03f663fba3f413f813f493f6a3fad, v2_double = {0x3f813f493f6a3fad,
0x3fb03f663fba3f41}, v4_float = {0x3f6a3fad,
0x3f813f49, 0x3fba3f41, 0x3fb03f66}, v4_int32 = {0x3f6a3fad, 0x3f813f49,
0x3fba3f41, 0x3fb03f66}, v8_int16 = {0x3fad, 0x3f6a, 0x3f49, 0x3f81, 0x3f41,
0x3fba, 0x3f66, 0x3fb0},
v16_int8 = {0xad, 0x3f, 0x6a, 0x3f, 0x49, 0x3f, 0x81, 0x3f, 0x41, 0x3f, 0xba,
0x3f, 0x66, 0x3f, 0xb0, 0x3f}}
(gdb) p/x $vs45
$34 = {float128 = 0x3f933f9e3f7a3f1a3f943fa73fb73fa9, uint128 =
0x3f933f9e3f7a3f1a3f943fa73fb73fa9, v2_double = {0x3f943fa73fb73fa9,
0x3f933f9e3f7a3f1a}, v4_float = {0x3fb73fa9,
0x3f943fa7, 0x3f7a3f1a, 0x3f933f9e}, v4_int32 = {0x3fb73fa9, 0x3f943fa7,
0x3f7a3f1a, 0x3f933f9e}, v8_int16 = {0x3fa9, 0x3fb7, 0x3fa7, 0x3f94, 0x3f1a,
0x3f7a, 0x3f9e, 0x3f93},
v16_int8 = {0xa9, 0x3f, 0xb7, 0x3f, 0xa7, 0x3f, 0x94, 0x3f, 0x1a, 0x3f, 0x7a,
0x3f, 0x9e, 0x3f, 0x93, 0x3f}}
so $vs44 contains the 16 bytes at $r2+$r30+16 and $vs45 contains the 16 bytes
at $r2+$r30+0 and the latter is used in the middle operand of the third
xvbf16ger2pp into $a5 and
the former in the fourth xvbf16ger2pp into $a5.
Now, with early scheduling, RA decided not to load it early, so does instead
lxvpx 32,28,2
xvbf16ger2pp 5,33,63
...
lxvx 32,28,2
xvbf16ger2pp 5,32,62
$r2+$r28 is the correct address to find the 32 bytes we need:
(gdb) x/4gx $r2+$r28
0x10020120 : 0x3f943fa73fb73fa9 0x3f933f9e3f7a3f1a
0x10020130 : 0x3f813f493f6a3fad 0x3fb03f663fba3f41
and lxvpx loads 32 bytes and then uses $vs33, so on little endian the first 16
bytes from that (aka what lxvx 33,28,2 would load too).
But what's wrong is lxvx 32,28,2 is wrong, we want at that point to use the 16
bytes at $r2+$r28+16, but get instead what is in $r2+$28+0.
So, I think there is some misunderstanding between the backend and RA on
endianity, what actually
(subreg:V16QI (reg:OO) 16)
and
(subreg:V16QI (reg:OO) 0)
mean for ppc64le and what it means on
(subreg:V16QI (mem:OO) 16)
and
(subreg:V16QI (mem:OO) 0)
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
--- Comment #17 from Jakub Jelinek ---
For that, in IRA dump we have
(insn 66 62 69 4 (set (reg:OO 181 [ _110 ])
(mem:OO (plus:DI (reg/f:DI 253 [ _255 ])
(reg:DI 119 [ ivtmp.80 ])) [0 MEM[(__vector_pair *)_255 +
ivtmp.80_3 * 1]+0 S32 A128])) "sbq.i":11:10 2209 {*movoo}
(expr_list:REG_EQUIV (mem:OO (plus:DI (reg/f:DI 253 [ _255 ])
(reg:DI 119 [ ivtmp.80 ])) [0 MEM[(__vector_pair *)_255 +
ivtmp.80_3 * 1]+0 S32 A128])
(nil)))
...
(insn 86 85 87 4 (set (reg:XO 200 [ _129 ])
(unspec:XO [
(reg:XO 196 [ _125 ])
(subreg:V16QI (reg:OO 181 [ _110 ]) 16)
(subreg:V16QI (reg:OO 209 [ _138 ]) 16)
] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
(expr_list:REG_DEAD (reg:XO 196 [ _125 ])
(nil)))
(...
(insn 90 89 91 4 (set (reg:XO 204 [ temp0$128 ])
(unspec:XO [
(reg:XO 200 [ _129 ])
(subreg:V16QI (reg:OO 181 [ _110 ]) 0)
(subreg:V16QI (reg:OO 209 [ _138 ]) 0)
] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
(expr_list:REG_DEAD (reg:XO 200 [ _129 ])
(expr_list:REG_DEAD (reg:OO 181 [ _110 ])
(nil
(in both ira dumps, the relative scheduling is the same, but there are
different insns in between).
reload dump with -fno-schedule-insns has then
(insn 66 62 69 5 (set (reg:OO 76 12 [orig:181 _110 ] [181])
(mem:OO (plus:DI (reg/f:DI 30 30 [orig:253 _255 ] [253])
(reg:DI 2 2 [orig:119 ivtmp.80 ] [119])) [0 MEM[(__vector_pair
*)_255 + ivtmp.80_3 * 1]+0 S32 A128])) "sbq.i":11:10 2209 {*movoo}
(expr_list:REG_EQUIV (mem:OO (plus:DI (reg/f:DI 30 30 [orig:253 _255 ]
[253])
(reg:DI 2 2 [orig:119 ivtmp.80 ] [119])) [0 MEM[(__vector_pair
*)_255 + ivtmp.80_3 * 1]+0 S32 A128])
(nil)))
...
(insn 86 85 87 5 (set (reg:XO 52 20 [orig:200 _129 ] [200])
(unspec:XO [
(reg:XO 52 20 [orig:200 _129 ] [200])
(reg:V16QI 77 13 [ _110+16 ])
(reg:V16QI 81 17 [ _138+16 ])
] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
(nil))
...
(insn 90 89 91 5 (set (reg:XO 52 20 [orig:204 temp0$128 ] [204])
(unspec:XO [
(reg:XO 52 20 [orig:204 temp0$128 ] [204])
(reg:V16QI 76 12 [orig:181 _110 ] [181])
(reg:V16QI 80 16 [orig:209 _138 ] [209])
] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
(nil))
and without that option insn 66 is gone, and
(insn 229 85 230 5 (set (reg:OO 64 0 [282])
(mem:OO (plus:DI (reg/f:DI 28 28 [orig:253 _255 ] [253])
(reg:DI 2 2 [orig:119 ivtmp.80 ] [119])) [0 MEM[(__vector_pair
*)_255 + ivtmp.80_3 * 1]+0 S32 A128])) 2209 {*movoo}
(nil))
(insn 230 229 86 5 (set (reg:V16QI 64 0 [283])
(reg:V16QI 65 1 [+16 ])) 1187 {vsx_movv16qi_64bit}
(nil))
(insn 86 230 233 5 (set (reg:XO 52 20 [orig:200 _129 ] [200])
(unspec:XO [
(reg:XO 52 20 [orig:200 _129 ] [200])
(reg:V16QI 64 0 [283])
(reg:V16QI 95 31 [ _138+16 ])
] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
(nil))
...
(insn 255 89 90 5 (set (reg:V16QI 64 0 [299])
(mem:V16QI (plus:DI (reg/f:DI 28 28 [orig:253 _255 ] [253])
(reg:DI 2 2 [orig:119 ivtmp.80 ] [119])) [0 MEM[(__vector_pair
*)_255 + ivtmp.80_3 * 1]+0 S16 A128])) 1187 {vsx_movv16qi_64bit}
(nil))
(insn 90 255 258 5 (set (reg:XO 52 20 [orig:204 temp0$128 ] [204])
(unspec:XO [
(reg:XO 52 20 [orig:204 temp0$128 ] [204])
(reg:V16QI 64 0 [299])
(reg:V16QI 94 30 [orig:209 _138 ] [209])
] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
(nil))
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
--- Comment #16 from Jakub Jelinek ---
So, the loop has exactly one iteration and in both cases all 8 MMA accumulators
are used, just in different orders, 0, 4, 5, 6, 7, 3, 1, 2 vs. 2, 4, 5, 6, 0,
7, 3, 1.
The first data difference is in $a5, I've put breakpoints on all the
xvbf16ger2pp insns with $a5 accumulator and compared the corresponding input
operands, and all have the same values except for the first input operand of
the last xvbf16ger2pp 5,...
insn.
Without any sched it is
0x1940 : dmxvbf16ger2pp a5,vs44,vs48
and
(gdb) p $vs44
$30 = {float128 = 2.06407030886103794578927588781383601e-24, uint128 =
84656493874352150699656209585058496429, v2_double = {0.0084214899518711642,
0.063467398222425878},
v4_float = {0.915034115, 1.00974381, 1.45505536, 1.37693477}, v4_int32 =
{1063927725, 1065434953, 1069170497, 1068515174}, v8_int16 = {16301, 16234,
16201, 16257, 16193, 16314,
16230, 16304}, v16_int8 = {-83, 63, 106, 63, 73, 63, -127, 63, 65, 63, -70,
63, 102, 63, -80, 63}}
(gdb) p $vs48
$31 = {float128 = 7.3295531861735777086128282856791316e-39, uint128 =
84407260535250187022019119464265957292, v2_double = {0.015257703121079512,
0.0079331342057285276}, v4_float = {
0.836909056, 1.11912322, 1.49412739, 1.00193012}, v4_int32 = {1062617004,
1066352494, 1069498257, 1065369407}, v8_int16 = {16300, 16214, 16238, 16271,
16273, 16319, 16191,
16256}, v16_int8 = {-84, 63, 86, 63, 110, 63, -113, 63, -111, 63, -65, 63,
63, 63, -128, 63}}
while with early sched it is
0x19a4 : dmxvbf16ger2pp a5,vs32,vs62
and
(gdb) p $vs32
$25 = {float128 = 3.84726360989932248572567852077824961e-33, uint128 =
84505921702154369525358723716408098729, v2_double = {0.019774068130402309,
0.018797371506081274}, v4_float = {
1.43163025, 1.15819252, 0.977525353, 1.15037894}, v4_int32 = {1068973993,
1066680231, 1064976154, 1066614686}, v8_int16 = {16297, 16311, 16295, 16276,
16154, 16250, 16286,
16275}, v16_int8 = {-87, 63, -73, 63, -89, 63, -108, 63, 26, 63, 122, 63,
-98, 63, -109, 63}}
(gdb) p $vs62
$26 = {float128 = 7.3295531861735777086128282856791316e-39, uint128 =
84407260535250187022019119464265957292, v2_double = {0.015257703121079512,
0.0079331342057285276}, v4_float = {
0.836909056, 1.11912322, 1.49412739, 1.00193012}, v4_int32 = {1062617004,
1066352494, 1069498257, 1065369407}, v8_int16 = {16300, 16214, 16238, 16271,
16273, 16319, 16191,
16256}, v16_int8 = {-84, 63, 86, 63, 110, 63, -113, 63, -111, 63, -65, 63,
63, 63, -128, 63}}
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #15 from Richard Biener --- (In reply to Alexander Monakov from comment #14) > Scheduling has sched_insn debug counter, may help to reduce down to one > reordering. I'd be hunting down insn combines / splits / simplifications as well, possibly disabling RTL passes one-by-one. sched1 should have an effect on RA and thus post-reload combines/splits.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #14 from Alexander Monakov --- Scheduling has sched_insn debug counter, may help to reduce down to one reordering.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #13 from Jakub Jelinek --- There are 32 xvbf16ger2pp instructions each in the above reduced testcase. With -fno-schedule-insns they obviously aren't reordered in any way, so 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 while without it they are 76 77 78 79 116 117 118 119 80 81 82 83 120 121 122 123 84 85 86 87 124 125 126 127 88 89 90 91 128 129 130 131
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #12 from Jakub Jelinek --- Created attachment 64172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64172&action=edit sbq.i Reduced testcase. ./cc1.r16-1782 -quiet -nostdinc -Ofast -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math sbq.i -o sbq1.s -g -fno-strict-aliasing -fno-schedule-insns2 -dP ./cc1.r16-1782 -quiet -nostdinc -Ofast -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math sbq.i -o sbq2.s -g -fno-strict-aliasing -fno-schedule-insns2 -fno-schedule-insns -dP gcc -o sbq-1 -xassembler sbq1.s gcc -o sbq-2 -xassembler sbq2.s ./sbq-1 > /tmp/1 ./sbq-2 > /tmp/2 diff -up /tmp/1 /tmp/2 --- /tmp/1 2026-04-08 05:47:29.087683379 -0400 +++ /tmp/2 2026-04-08 05:47:25.917684219 -0400 @@ -2,14 +2,14 @@ 1 4106a670410212a0.40f308a0411a7ba0.40e1f50040d9c1e0.40cc53404102cd80 2 40ca83a040c26d20.40b849e040e83a00.4118f100410dde00.4108e230412dab80 3 41091f4040f02c00.40e56dc041158580.4103e2c040f07ec0.40cf718041128310 -4 4120e1e041132240.410e008041304600.4113a4204102ba20.410041604125c100 -5 40d50b4040b8be40.40af7e8040ed71a0.411c28a04110aa20.4101d4a0412c4a90 -6 41256eb04117f6d0.410721c04133bde0.40e5d8c040d0a3c0.40c675204101ada0 -7 4102868040df8300.40d0bcc0410c8940.40f1552040c5b060.40c46ca041021c40 -8 4118e66041162390.410aa390412dcb20.411ae88041121d60.41075940412d5320 -9 410ba4a041014b00.40f2e6c0411c89d0.410d734041080730.40f53760411fc5e0 -10 40e7d06040d7ce20.40dc93204102edc0.40c4344040ce9960.40c7a54040ec31c0 -11 40db416040cbdb20.40c0d44040f6fec0.41034cc0410327b0.40fb612041182ea0 +4 41182160410ce8c0.4106200041248780.4109428040eb24c0.40ef5b604118cb20 +5 40ea9d0040cc0ac0.40c261a04104dc70.411b3620410c78e0.41017200412b9c90 +6 411947304105b710.40faefc041250be0.40d7114040c58000.40b93d4040efa140 +7 40e0e4c040be9fc0.40b125c040e9c240.40ddfde040b6f960.40b3250040ea6dc0 +8 4122ee80411d7bb0.4113a3d0413b3840.41177060410a5fe0.4104ed3041298e40 +9 4104ea0040ef8600.40e80ca041144e70.41198d204111f950.41055250412fc940 +10 4101cd9040f736a0.40f40ac0411498e0.40d67f4040dcc5e0.40d7f480410245e0 +11 40fee4e040ef98a0.40df864041128920.410f4ee0410cde90.4108577041281940 12 411257e04109adc0.40fb8d2041222320.410875f041020550.40e9998041188fe0 13 41139a804102ad70.40f81ee04125ea30.40f1598040d6a0c0.40d372e041081de0 14 40ee154040e2fc60.40d4a2a0410977a0.410fbba0410b4d10.4100ac504122b070
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
--- Comment #11 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #7)
> E.g. the vregs dump has 88 UNSPEC_MMA_EXTRACT in r16-1781, so the commit
> changed 88 spots in the function, like
> (insn 45 44 46 5 (set (reg:V16QI 325 [ _276 ])
> -(unspec:V16QI [
> -(reg:OO 324 [ _275 ])
> -(const_int 0 [0])
> -] UNSPEC_MMA_EXTRACT)) 2212 {*vsx_disassemble_pair}
> +(subreg:V16QI (reg:OO 324 [ _275 ]) 0)) 1187 {vsx_movv16qi_64bit}
> (nil))
> or
> (insn 268 267 269 14 (set (reg:V16QI 405 [ _380 ])
> -(unspec:V16QI [
> -(reg:XO 404 [ _379 ])
> -(const_int 0 [0])
> -] UNSPEC_MMA_EXTRACT)) 2214 {*mma_disassemble_acc}
> +(subreg:V16QI (reg:XO 404 [ _379 ]) 0)) 1187 {vsx_movv16qi_64bit}
> (nil))
> Already before combine those result in changes like
> -(insn 45 44 46 4 (set (reg:V16QI 325 [ _276 ])
> -(unspec:V16QI [
> -(reg:OO 324 [ _275 ])
> -(const_int 0 [0])
> -] UNSPEC_MMA_EXTRACT)) 2212 {*vsx_disassemble_pair}
> - (nil))
> -(insn 46 45 47 4 (set (reg:V16QI 326 [ _277 ])
> -(unspec:V16QI [
> -(reg:OO 324 [ _275 ])
> -(const_int 1 [0x1])
> -] UNSPEC_MMA_EXTRACT)) 2212 {*vsx_disassemble_pair}
> - (expr_list:REG_DEAD (reg:OO 324 [ _275 ])
> -(nil)))
> -(insn 47 46 48 4 (set (reg:OO 285 [ _232 ])
> +(insn 47 44 51 4 (set (reg:OO 285 [ _232 ])
> (mem:OO (plus:DI (reg/v/f:DI 464 [ ap ])
> (reg:DI 456 [ ivtmp.164 ])) [0 MEM[(__vector_pair
> *)ap_115(D) + ivtmp.164_654 * 1]+0 S32 A128])) "sbg.i":15063:10 2209 {*movoo}
> (nil))
> ...
> (insn 83 82 84 4 (set (reg:XO 317 [ _264 ])
> (unspec:XO [
> (reg:XO 313 [ _260 ])
> -(reg:V16QI 290 [ _237 ])
> -(reg:V16QI 326 [ _277 ])
> -] UNSPEC_MMA_XVBF16GER2PP)) 2234 {mma_xvbf16ger2pp}
> +(subreg:V16QI (reg:OO 288 [ _235 ]) 16)
> +(subreg:V16QI (reg:OO 324 [ _275 ]) 16)
> +] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
> (expr_list:REG_DEAD (reg:XO 313 [ _260 ])
> -(expr_list:REG_DEAD (reg:V16QI 290 [ _237 ])
> -(nil
> +(nil)))
> (insn 84 83 85 4 (set (reg:XO 318 [ _265 ])
> (unspec:XO [
> (reg:XO 314 [ _261 ])
> -(reg:V16QI 296 [ _243 ])
> -(reg:V16QI 326 [ _277 ])
> -] UNSPEC_MMA_XVBF16GER2PP)) 2234 {mma_xvbf16ger2pp}
> +(subreg:V16QI (reg:OO 294 [ _241 ]) 16)
> +(subreg:V16QI (reg:OO 324 [ _275 ]) 16)
> +] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
> (expr_list:REG_DEAD (reg:XO 314 [ _261 ])
> -(expr_list:REG_DEAD (reg:V16QI 296 [ _243 ])
> -(nil
> +(nil)))
Are the register (and esp. memory offsets in that correct? This presumably
is for wrong-endian even?
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #10 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #2) > And both r16-1782 and r16-2580 print the same thing as the older revisions > when > compiled with -O0 -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math. -mtune=power10 and -mvsx in that are totally superfluous (the -mcpu=power10 implies those already).
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
--- Comment #9 from Jakub Jelinek ---
Tried now:
--- sbg.i 2026-04-07 20:06:42.267145618 +0200
+++ sbq.i 2026-04-08 11:15:21.257059016 +0200
@@ -15624,6 +15624,8 @@ inline __attribute__((always_inline))
vec_reduce_4 (temp00 + 16, temp0 + 4);
}
+__vector_quad semp0[8];
+
[[gnu::noipa]] static void
BF16GEMV_T_MMA_8 (BLASLONG n, BLASLONG lda, bfloat16 *ap, bfloat16 *x, float
*y, float alpha)
{
@@ -15680,6 +15682,14 @@ BF16GEMV_T_MMA_8 (BLASLONG n, BLASLONG l
vec_loadN_mult14_mma (&temp0[0], &va0[i], &va1[i], &va2[i], &va3[i],
inp[0], n);
vec_loadN_mult14_mma (&temp0[4], &va4[i], &va5[i], &va6[i], &va7[i],
inp[0], n);
}
+semp0[0] = temp0[0];
+semp0[1] = temp0[1];
+semp0[2] = temp0[2];
+semp0[3] = temp0[3];
+semp0[4] = temp0[4];
+semp0[5] = temp0[5];
+semp0[6] = temp0[6];
+semp0[7] = temp0[7];
vec_reduce_8 (temp00, &temp0[0]);
vec_f32 t0, t1, t2, t3, t4, t5, t6, t7, t10, t11, t12, t13, t14, t15, t16,
t17;
vec_f32 a = { alpha, alpha, alpha, alpha };
and dumping the semp0 array at the end (- is with -fno-schedule-insns, +
without):
0x100206c0 :4679821243262199392 4674205350185763168
0x100206d0 : 4686549429791146672 4679941639787866080
0x100206e0 : 4685615463382782624 4680093922148121504
0x100206f0 : 4675287269624103392 4669198449110076800
0x10020700 : 4668688688027430176 4663558641652611584
0x10020710 : 4690763995300093440 4686244109158820736
0x10020720 : 4686311248083561472 4676264460587206016
0x10020730 :4684837352746548928 4670076134267978512
-0x10020740 :4690535709198313664 4685467647790581632
-0x10020750 :4686350005868111040 4679059006828366624
-0x10020760 :4677723787390356160 4666399504822754416
-0x10020770 :4691402948994693344 4684150432860970128
-0x10020780 :4690858759457978128 4682318371610758112
-0x10020790 :467106082443264 4663826235295506752
-0x100207a0 :4674987927581663168 4661548596958184000
-0x100207b0 :4674171127880677728 4662110722277928384
-0x100207c0 :4693575996289153968 4689271751865743424
-0x100207d0 :4690341095640031200 4685130303879614016
-0x100207e0 :4685126799182497280 4677002095450410608
-0x100207f0 :4690935656553249104 4685241491993381184
-0x10020800 :4684251106890954400 4680377733586655456
-0x10020810 :4672061577386313184 4672471970103838176
-0x10020820 :4683432314325145760 4674602548761626912
-0x10020830 :4688052462186978960 4686091551920101696
+0x10020740 :4692999165000753728 4687684812988761600
+0x10020750 :4689272095459424800 4683815494130974976
+0x10020760 :4671652559058419264 4661083228661969312
+0x10020770 :4691669580564703776 4684258872195304080
+0x10020780 :4694279889888999120 4685751046913637856
+0x10020790 :4676382108326863808 4667546845206130080
+0x100207a0 :4684454447821062912 4670440347494287680
+0x100207b0 :4679615084828668000 4666974549403900992
+0x100207c0 :4690752312989590416 4686738202196560672
+0x100207d0 :4691317599404957024 4685812069808558880
+0x100207e0 :4687020845401459456 4680056676191865296
+0x100207f0 :4687529506968700720 4680708274270488032
+0x10020800 :4676935849870872096 4673772280042679744
+0x10020810 :4666912564432509280 4667881234178519488
+0x10020820 :4673400919986789152 4665962586388758208
+0x10020830 :4684672426003605424 4682443028740714144
0x10020840 :4688906782721551808 4682491407252988704
0x10020850 :4686125087022253392 4677438464127963104
0x10020860 :4689261512660004208 4681525761166142000
0x10020870 :4679619895193149632 4671203546002628064
0x10020880 :4678700428595231840 4671537522659653536
0x10020890 :4688172034076396816 4683933073155469424
0x100208a0 :4677657266938642464 4670066376101147888
0x100208b0 :4692166559821084560 4688207012292798080
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #8 from Jakub Jelinek --- Comparing now r16-1782 ./cc1.r16-1782 -quiet -nostdinc -Ofast -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math sbg.i -o sbg1.s -g -fno-strict-aliasing -fno-schedule-insns2 -dP vs. ./cc1.r16-1782 -quiet -nostdinc -Ofast -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math sbg.i -o sbg2.s -g -fno-strict-aliasing -fno-schedule-insns2 -fno-schedule-insns -dP under debugger. Both have exactly 8 vmrgew instructions, and they weren't reordered, grep -B8 '\t'vmrgew sbg1.s | grep insn #(insn 1791 2246 1800 (set (reg:V4SF 64 0 [517]) #(insn 1810 2248 1781 (set (reg:V4SF 73 9 [527]) #(insn 1827 2250 1834 (set (reg:V4SF 68 4 [538]) #(insn 1842 2252 1819 (set (reg:V4SF 69 5 [549]) #(insn 1861 2254 1870 (set (reg:V4SF 65 1 [559]) #(insn 1880 2256 1851 (set (reg:V4SF 76 12 [569]) #(insn 1897 2258 1904 (set (reg:V4SF 70 6 [580]) #(insn 1912 2260 1889 (set (reg:V4SF 71 7 [591]) grep -B8 '\t'vmrgew sbg2.s | grep insn #(insn 1791 2191 3926 (set (reg:V4SF 64 0 [517]) #(insn 1810 2193 3928 (set (reg:V4SF 77 13 [527]) #(insn 1827 2195 1829 (set (reg:V4SF 76 12 [538]) #(insn 1842 2197 1844 (set (reg:V4SF 64 0 [549]) #(insn 1861 2199 3936 (set (reg:V4SF 64 0 [559]) #(insn 1880 2201 3938 (set (reg:V4SF 76 12 [569]) #(insn 1897 2203 1899 (set (reg:V4SF 75 11 [580]) #(insn 1912 2205 1914 (set (reg:V4SF 64 0 [591]) The operands of the first two insns are the same between the two runs, but the third one differs (in v16_int8): --64, -93, -48, 64, -64, -40, -27, 64, -96, -83, 1, 65, 32, 117, -58, 64 -32, -70, 2, 65, 32, -92, 19, 65, 0, -63, 37, 65, 96, 65, 0, 65 +0, -128, -59, 64, 64, 17, -41, 64, 64, -95, -17, 64, 64, 61, -71, 64 +-64, 36, -21, 64, -128, 66, 9, 65, 32, -53, 24, 65, 96, 91, -17, 64 Though, insn 1791 is already clearly the 15689 t2 = __builtin_vec_vmrgow (temp00[1], temp00[5]); and insn 1810 15693 t6 = __builtin_vec_vmrgow (temp00[3], temp00[7]); and so insn 1827 (the one with different arguments) is I think 15690 t3 = __builtin_vec_vmrgow (temp00[9], temp00[13]);
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
--- Comment #7 from Jakub Jelinek ---
E.g. the vregs dump has 88 UNSPEC_MMA_EXTRACT in r16-1781, so the commit
changed 88 spots in the function, like
(insn 45 44 46 5 (set (reg:V16QI 325 [ _276 ])
-(unspec:V16QI [
-(reg:OO 324 [ _275 ])
-(const_int 0 [0])
-] UNSPEC_MMA_EXTRACT)) 2212 {*vsx_disassemble_pair}
+(subreg:V16QI (reg:OO 324 [ _275 ]) 0)) 1187 {vsx_movv16qi_64bit}
(nil))
or
(insn 268 267 269 14 (set (reg:V16QI 405 [ _380 ])
-(unspec:V16QI [
-(reg:XO 404 [ _379 ])
-(const_int 0 [0])
-] UNSPEC_MMA_EXTRACT)) 2214 {*mma_disassemble_acc}
+(subreg:V16QI (reg:XO 404 [ _379 ]) 0)) 1187 {vsx_movv16qi_64bit}
(nil))
Already before combine those result in changes like
-(insn 45 44 46 4 (set (reg:V16QI 325 [ _276 ])
-(unspec:V16QI [
-(reg:OO 324 [ _275 ])
-(const_int 0 [0])
-] UNSPEC_MMA_EXTRACT)) 2212 {*vsx_disassemble_pair}
- (nil))
-(insn 46 45 47 4 (set (reg:V16QI 326 [ _277 ])
-(unspec:V16QI [
-(reg:OO 324 [ _275 ])
-(const_int 1 [0x1])
-] UNSPEC_MMA_EXTRACT)) 2212 {*vsx_disassemble_pair}
- (expr_list:REG_DEAD (reg:OO 324 [ _275 ])
-(nil)))
-(insn 47 46 48 4 (set (reg:OO 285 [ _232 ])
+(insn 47 44 51 4 (set (reg:OO 285 [ _232 ])
(mem:OO (plus:DI (reg/v/f:DI 464 [ ap ])
(reg:DI 456 [ ivtmp.164 ])) [0 MEM[(__vector_pair *)ap_115(D)
+ ivtmp.164_654 * 1]+0 S32 A128])) "sbg.i":15063:10 2209 {*movoo}
(nil))
...
(insn 83 82 84 4 (set (reg:XO 317 [ _264 ])
(unspec:XO [
(reg:XO 313 [ _260 ])
-(reg:V16QI 290 [ _237 ])
-(reg:V16QI 326 [ _277 ])
-] UNSPEC_MMA_XVBF16GER2PP)) 2234 {mma_xvbf16ger2pp}
+(subreg:V16QI (reg:OO 288 [ _235 ]) 16)
+(subreg:V16QI (reg:OO 324 [ _275 ]) 16)
+] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
(expr_list:REG_DEAD (reg:XO 313 [ _260 ])
-(expr_list:REG_DEAD (reg:V16QI 290 [ _237 ])
-(nil
+(nil)))
(insn 84 83 85 4 (set (reg:XO 318 [ _265 ])
(unspec:XO [
(reg:XO 314 [ _261 ])
-(reg:V16QI 296 [ _243 ])
-(reg:V16QI 326 [ _277 ])
-] UNSPEC_MMA_XVBF16GER2PP)) 2234 {mma_xvbf16ger2pp}
+(subreg:V16QI (reg:OO 294 [ _241 ]) 16)
+(subreg:V16QI (reg:OO 324 [ _275 ]) 16)
+] UNSPEC_MMA_XVBF16GER2PP)) 2232 {mma_xvbf16ger2pp}
(expr_list:REG_DEAD (reg:XO 314 [ _261 ])
-(expr_list:REG_DEAD (reg:V16QI 296 [ _243 ])
-(nil
+(nil)))
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
--- Comment #6 from Jakub Jelinek ---
Attached, basically everything changes.
With r16-1782
-O2 -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math -fno-strict-aliasing
doesn't help, nor
-O2 -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math -fno-strict-aliasing
-fno-schedule-insns2
but
-O2 -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math -fno-strict-aliasing
-fno-schedule-insns
or
-O2 -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math -fno-strict-aliasing
-fno-schedule-insns{,2}
does help.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #5 from Jakub Jelinek --- Created attachment 64171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64171&action=edit Assembler from r16-1782
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #4 from Jakub Jelinek --- Created attachment 64170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64170&action=edit Assembler from r16-1781
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
Do -fno-strict-aliasing / -fno-schedule-insns{,2} help? IIRC openBLAS is quite
sloppy in this area and intrinsics might not be "safe". Otherwise is there any
big assembler difference from the bisected revision? (without now building a
cross myself)
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |16.0 Priority|P3 |P1 CC||bergner at gcc dot gnu.org, ||kishan at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #2 from Jakub Jelinek --- And both r16-1782 and r16-2580 print the same thing as the older revisions when compiled with -O0 -mcpu=power10 -mtune=power10 -mvsx -fno-fast-math.
[Bug target/124804] [16 Regression] Possible openblas miscompilation since r16-1782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124804 --- Comment #1 from Jakub Jelinek --- Created attachment 64163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64163&action=edit pr124804.c.xz
