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