https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #40 from John David Anglin <danglin at gcc dot gnu.org> ---
Jeff,
I don't think these split instructions make a lot of sense on PA-RISC.
(insn 280 277 281 30 (set (reg/f:SI 20 %r20 [480])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
(const_int 396 [0x18c]))) "../Python/compile.c":5970:20 120
{addsi3}
(nil))
(insn 281 280 284 30 (set (mem:SI (reg/f:SI 20 %r20 [480]) [4 MEM[(int *)_107 +
396B]+0 S4 A32])
(reg:SI 12 %r12 [orig:134 vect_pretmp_36.2452 ] [134]))
"../Python/compile.c":5970:20 42 {*pa.md:2193}
(nil))
They increase code size and register pressure. That may lead to unnecessary
spills and longer branches. They increase probability of problems like the
one in this PR.
I suspect the two instructions generated are actually slower than one with a
nonzero memory offset. It's not clear that memory accesses with a zero offset
are faster than ones with nonzero offsets.
Integer loads and stores on pa support fairly large offsets.
I think we need to look at why this happens frequently.
Thoughts?
