https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the optimization issue, we could have a hack like:
--- gcc/postreload.c.jj 2020-04-07 16:54:23.638924247 +0200
+++ gcc/postreload.c 2020-04-07 17:06:44.055964581 +0200
@@ -328,6 +328,17 @@ reload_cse_simplify_set (rtx set, rtx_in
else
continue;
+ /* Prefer stack pointer adjustment over copies from a register
+ that happens to hold the right value already (unless it is
+ much higher cost), because in the sp += const case the
+ pass_stack_adjustments pass can merge it with other stack
+ adjustments. */
+ if (SET_DEST (set) == stack_pointer_rtx
+ && GET_CODE (SET_SRC (set)) == PLUS
+ && XEXP (SET_SRC (set), 0) == stack_pointer_rtx
+ && CONST_INT_P (XEXP (SET_SRC (set), 1)))
+ this_cost *= 4;
+
/* If equal costs, prefer registers over anything else. That
tends to lead to smaller instructions on some machines. */
if (this_cost < old_cost
Dunno... :(
Or do such a change only if there are no following sp adjustments that could be
combined with it (e.g. remember we've done such a change, and when we process
next stack pointer adjustment with no sp uses in between or what exactly csa
does, and don't manage to optimize that one into sp = reg, try to undo the
previous change.
