[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94

["manolis.tsamis at vrull dot eu" <gcc-bugzilla@gcc.gnu.org>]

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.