https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |smunnangi1 at ventanamicro dot
com
--- Comment #5 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So a bit of clarification here from the patchwork meeting today.
Shreya's work isn't meant to directly fix this particular issue, though it is
very closely related and likely a prerequisite to fix this issue.
What Shreya is doing is adjusting the addsi3/adddi3 code. First she's going to
create an addsi3/adddi3 expander. Those expanders will widen the set of valid
operands to allow more constants for the 2nd input operand.
The existing addsi3/adddi3 define_insns will need a name change to *addsi3 and
*adddi3 to indicate the names are internal.
In the new expanders for a case like x+2048, rather than construct the 2048
constant into a register and using the add instruction, instead generate
addi+addi during initial RTL generation. There's also cases we can handle with
shNadd. So we effectively avoid constant synthesis and generate efficient code
at initial RTL generation.
We would then remove the special define_insn_and_split for the sum of two
simm12 cases.
Once that's done I think we define add_ptr3 (or whatever it's called). That
expander/pattern is special for LRA's use in generating more efficient code in
some cases. I'm pretty sure we can define it as an expander and use the same
code as we're using for addsi3/adddi3.
That should result in getting reasonable code out of LRA for this case and in a
form that fold-mem-offsets can likely handle rather than waiting for sched2 to
do the height reduction transformation and leaving the useless add instruction
in the RTL stream.
Anyway, that's the basic plan.
