Re: fwprop addressing costs

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Jun 1, 2018 at 8:59 AM Robin Dapp <rdapp@linux.ibm.com> wrote:
>
> Hi,
>
> when investigating a regression, I realized that we create a superfluous
> load on S390.  The snippet looks something like
>
> LA  %r10, 0(%r8,%r9)
> LLH %r4, 0(%r10)
>
> meaning the address in r10 is computed by an LA even though LLH supports
> the addressing already.  The same address is used multiple times so
> combine cannot do something about it.
>
> Looking into fwprop, I realized it actually tries to propagate the
> address but exits because we specify higher costs for an address with
> index than for one without.  This was meant to account for the fact
> that, in general and all other things being equal, not every instruction
> can handle indexed addressing mode.
>
> Now, in this case, fwprop actually knows the instructions it propagates
> into and could decide based on the full costs, seeing that it would not
> be more expensive.  Currently, it recursively descends to the parts that
> are going to be propagated or replaced and compares the costs of both
> without regarding the full instruction.
>
> Would it make sense to enhance fwprop with a more detailed cost
> evaluation or are there other passes that should do the same - i.e.
> what's the preferred way to solve this? Is changing the address costs in
> the backend depending on addressing mode sensible at all? As far as I
> can see, the x86 backend also changes costs depending on global
> properties (i.e. to prefer fewer registers when addressing).

forwprop could possibly use the new insn_cost hook

> Regards
>  Robin
>