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?
