On 9/20/26 11:18 AM, Matt Turner wrote:
Only the 8-byte vector modes had movmisalign patterns, so for scalar
modes gimple_fold_builtin_memory_op refused to fold a small memcpy into
a plain load or store: STRICT_ALIGNMENT is set and no unaligned move was
available. The call survived to expand and was handled either by
move_by_pieces or by alpha_expand_block_move, and in both cases the
destination or the source had to stay addressable, so it got a stack
slot.
For a 4-byte load on a BWX target this produced four ldbu, four stb into
that slot and a final ldl, which is worse than the ldq_u/extll/extlh
sequence a pre-BWX target gets, because MOVE_RATIO is 7 with BWX and
by-pieces then copies a byte at a time. Even on a pre-BWX target the
now-dead stack slot kept a 16-byte frame alive in what is otherwise a
leaf function needing no frame at all.
Extend the movmisalign mode iterator to HImode, SImode and DImode and
derive the access size from the mode rather than hardcoding 8. The
memcpy is then folded at gimple time into a load or a store of a
type with reduced alignment, which expands to the unaligned sequence
directly, with no stack slot, no frame, and no by-pieces byte copy.
-msafe-partial keeps emitting byte stores for the store case.
gcc/ChangeLog:
* config/alpha/alpha.cc (alpha_expand_movmisalign): Derive the
access size from MODE rather than assuming 8 bytes.
* config/alpha/alpha.md (MISALIGN): New mode iterator.
(movmisalign<mode>): Use it in place of VEC.
gcc/testsuite/ChangeLog:
* gcc.target/alpha/movmisalign-si.c: New test.
* gcc.target/alpha/movmisalign-si-bwx.c: New test.
* gcc.target/alpha/movmisalign-hi-bwx.c: New test.
* gcc.target/alpha/movmisalign-run.c: New test.
THanks. I've pushed this to the trunk.
jeff
