New optimization for reload_combine
Paolo Bonzini
bonzini@gnu.org
Fri Jul 16 19:45:00 GMT 2010
On 07/16/2010 12:34 PM, Bernd Schmidt wrote:
> This fixes one subproblem of PR42235. In reload_combine, we recognize a
> new pattern:
>
> REG1 = REG2 + CONST
> ...
> something MEM (REG1)
>
> and try to use the addition in the MEM directly, moving the add insn
> downwards if REG1 and REG2 are identical. This has two benefits: it may
> be possible to eliminate the add, and the load no longer depends on the
> add instruction and may schedule sooner.
>
> This can make the generated code quite a lot nicer:
>
> - adds r3, r2, #2
> strb r5, [r2, #0]
> - strb r5, [r3, #0]
> - adds r3, r2, #3
> + strb r5, [r2, #2]
> strb r5, [r2, #1]
> - strb r5, [r3, #0]
> - adds r3, r2, #4
> + strb r5, [r2, #3]
> lsrs r1, r1, #11
> - strb r5, [r3, #0]
> - adds r3, r2, #5
> + strb r5, [r2, #4]
> add r1, r1, r1, lsl #1
> - strb r5, [r3, #0]
> + strb r5, [r2, #5]
Nice. :) I suppose fwprop doesn't do it because the memory accesses are
not present before reload?
Can you make the change dependent on
bool speed = optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn));
/* Prefer the new address if it is less expensive. */
gain = (address_cost (old_rtx, mode, as, speed)
- address_cost (new_rtx, mode, as, speed));
/* If the addresses have equivalent cost, prefer the new address
if it has the highest `rtx_cost'. That has the potential of
eliminating the most insns without additional costs, and it
is the same that cse.c used to do. */
if (gain == 0)
gain = rtx_cost (new_rtx, SET, speed) - rtx_cost (old_rtx, SET, speed);
return (gain > 0);
as in fwprop (in turn taken from CSE)?
> Does postreload.c fall under reload? If not, would someone approve this?
Well, it was part of reload1.c until a while ago...
Paolo
More information about the Gcc-patches
mailing list