https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120528
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Michael Meissner <[email protected]>: https://gcc.gnu.org/g:956d39b165f95b842432ba9ca4f97d6474196fd5 commit r17-3139-g956d39b165f95b842432ba9ca4f97d6474196fd5 Author: Michael Meissner <[email protected]> Date: Fri Aug 7 11:09:22 2026 -0400 PR target/120528 -- Simplify zero extend from memory to VSX register on power10 Previously GCC would zero extend a DImode value in memory to a TImode target in a vector register by firt zero extending the DImode value into a GPR TImode register pair, and then do a MTVSRDD to move this value to a VSX register. For example, consider the following code: #ifndef TYPE #define TYPE unsigned long long #endif void mem_to_vsx (TYPE *p, __uint128_t *q) { /* lxvrdx 0,0,3 stxv 0,0(4) */ __uint128_t x = *p; __asm__ (" # %x0" : "+wa" (x)); *q = x; } It currently generates the following code on power10: mem_to_vsx: ld 10,0(3) li 11,0 mtvsrdd 0,11,10 #APP # 0 #NO_APP stxv 0,0(4) blr Instead it could generate: mem_to_vsx: lxvrdx 0,0,3 #APP # 0 #NO_APP stxv 0,0(4) blr The lxvr{b,h,w,d}x instructions were added in power10, and they load up a vector register with a byte, half-word, word, or double-word value in the right most bits, and fill the remaining bits to 0. I noticed this code when working on PR target/108958 (which I just posted the patch). This patch creates a peephole2 to catch this case, and it eliminates creating the TImode variable. Instead it just does the LXVR{B,H,W,D}x instruction directly. 2026-08-07 Michael Meissner <[email protected]> gcc/ PR target/120528 * config/rs6000/rs6000.md (zero_extend??ti2 peephole2): Add a peephole2 to simplify zero extending a QI/HI/SI/DImode value in memory to a TImode target in a vector register to use the LXVR{B,H,W,D}X instructins. gcc/testsuite/ PR target/120528 * gcc.target/powerpc/pr120528.c: New test.
