https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
--- Comment #7 from Shreya Munnangi <smunnangi1 at ventanamicro dot com> --- Sure, I'll go ahead with this. On Tue, Aug 12, 2025 at 2:07 PM law at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811 > > --- Comment #6 from Jeffrey A. Law <law at gcc dot gnu.org> --- > It does look viable to fix this problem using Shreya's work. But there's > one > notable caveat. > > So I created an expander "addptr<mode>3" which is the magic expander that > gets > used by LRA when it needs to reload address computations due to an out of > range > index. > > ;; This is meant to improve the code we generate for cases when > ;; we need to access the current frame and the offsets are too > ;; large. This pattern is not allowed to fail, so in the worst > ;; case scenario we'll synthesize the constant into a register > ;; and emit a reg-reg add. > (define_expand "addptr<mode>3" > [(set (match_operand:X 0 "register_operand") > (plus:X (match_operand:X 1 "register_operand") > (match_operand 2 "const_int_operand")))] > "" > { > gcc_assert (CONST_INT_P (operands[2])); > bool status = synthesize_add (operands); > gcc_assert (status); > DONE; > }) > > That's only been lightly tested. > > That will get the right code coming out of LRA. But post-reload combine > squashes the two addis back together with the adddi3_const_sum_of_two_s12 > pattern. THe expectation is that pattern should just get removed as part > of > this work. Sure enough if I remove that pattern we get a much more > favorable > post-reload combine -- the second addi gets combined with a memory > reference. > > Shreya, want to pick this up next? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
