https://gcc.gnu.org/g:e0ecf9084c10fdd690b3dae5a5a402f506f828b0
commit e0ecf9084c10fdd690b3dae5a5a402f506f828b0 Author: Michael Meissner <[email protected]> Date: Thu Jul 2 20:02:55 2026 -0400 Update ChangeLog.* Diff: --- gcc/ChangeLog.dmf | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/gcc/ChangeLog.dmf b/gcc/ChangeLog.dmf index 716a15109828..6fd090fd33dc 100644 --- a/gcc/ChangeLog.dmf +++ b/gcc/ChangeLog.dmf @@ -1,3 +1,77 @@ +==================== Branch work250-dmf, patch #131 ==================== + +Fix dense math register insert/extract 512-bit problem. + +Kishan Parmar <[email protected]> issued a patch that made me re-examine the +code I had put out for dense math registers. This patch fixes the third problem +the patch uncovered. + +The first problem is the insert/extract instructions were using %<n> to address +VSX registers instead of using %x<n>. This would give the wrong register number +if a vector register 32..63 was used (i.e. a traditional Altivec register). + +The second problem was the instructions were using %L<n> to access the second +vector pair register, which does not work for Altivec registers either without +the patch. + +I have rewritten the instructions to use %x<n> for the first vector pair +register, and %x<n>+2 to access the second vector pair register. + +I have committed all of the patches in my backlog (dense math registers, other +-mcpu=future instructions, random bug fixes, support for _Float16 and +__bfloat16, and optimizations for vector logical operations on power10/power11) +into the IBM vendor branch: + + vendors/ibm/gcc-17-future + +I have tested these patches on both big endian and little endian PowerPC +servers, with no regressions. Can I check these patches into the trunk? + +2026-07-02 Michael Meissner <[email protected]> + +gcc/ + + * config/rs6000/mma.md (movxo_dm): Fix issues if vector registers 32..63 + were used. + (movtdo_insert512_upper): Likewise. + (movtdo_insert512_lower): Likewise. + (movtdo_extract512): Likewise. + +==================== Branch work250-dmf, patch #130 ==================== + +Fix -mregnames issue with dense math registers. + +Kishan Parmar <[email protected]> issued a patch that made me re-examine the +code I had put out for dense math registers. This patch fixes two of these problems. + +The first problem is the output operand %A<n> was always printing out a number, +even if -mregnames was used. I fixed this by using reg_names[..] for dense math +registers. For power10/power11 accumulators that are overlaid on top of VSX +registers, it just prints out the VSX register number divided by 4. + +The second problem is once %A<n> can print a register name instead of a number, +the next problem is if you use -mregnames, GCC would put out %dmr<n> while the +assembler wants %dm<n>. I fixed this to use the correct name. + +I have committed all of the patches in my backlog (dense math registers, other +-mcpu=future instructions, random bug fixes, support for _Float16 and +__bfloat16, and optimizations for vector logical operations on power10/power11) +into the IBM vendor branch: + + vendors/ibm/gcc-17-future + +I have tested these patches on both big endian and little endian PowerPC +servers, with no regressions. Can I check these patches into the trunk? + +2026-07-02 Michael Meissner <[email protected]> + +gcc/ + + * config/rs6000/rs6000.cc (alt_reg_names): Use %dm<n> for dense math + registers, not %dmr<n>. + (print_operand): Add a comment for %A<n>, of why we can't emit %dm<n> + since the assembler doesn't recognize %dm0 in this context. + ==================== Branch work250-dmf, patch #120 ==================== Add paddis support.
