https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #45 from Manolis Tsamis <manolis.tsamis at vrull dot eu> ---
(In reply to Jeffrey A. Law from comment #41)
> I would agree. In fact,the whole point of the f-m-o pass is to bring those
> immediates into the memory reference. It'd be really useful to know why
> that isn't happening.
>
> The only thing I can think of would be if multiple instructions needed the
> %r20 in the RTL you attached. Which might point to a refinement we should
> make in f-m-o, specifically the transformation isn't likely profitable if we
> aren't able to fold away a term or fold a constant term into the actual
> memory reference.
Jeff,
I'm confused about "It'd be really useful to know why that isn't happening.".
It can be seen in Dave's dumps that it *is* happening, e.g.:
Memory offset changed from 0 to 396 for instruction:
(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))
Instruction folded:(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))
If you looks at the RTL in f-m-o all these offsets are indeed moved in the
respective load/store. I don't know if cprop afterwards manages to eliminate
the unwanted move, but f-m-o does what it's supposed to do in this case.
