On Fri, Jun 1, 2018 at 8:59 AM Robin Dapp <rd...@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 >
