On 21/10/2019 16:46, Segher Boessenkool wrote:
On Mon, Oct 21, 2019 at 03:46:53PM +0100, Richard Earnshaw (lists) wrote:
On 19/10/2019 14:00, Segher Boessenkool wrote:
On Fri, Oct 18, 2019 at 08:48:40PM +0100, Richard Earnshaw wrote:
The cost routine for Arm and Thumb2 was not recognising the idioms that
describe the addition with carry, this results in the instructions
appearing more expensive than they really are, which occasionally can lead
to poor choices by combine. Recognising all the possible variants is
a little trickier than normal because the expressions can become complex
enough that this is no single canonical from.
There also is the insn_cost hook, which especially for RISC-like targets
is a lot easier to define.
Easier, but not a complete replacement for rtx_costs, so not necessarily
easier in the end...
It isn't a full replacement *yet*, still chipping away at it. If your
port has an rtx_cost already, adding ai reasonable insn_cost will only
improve it, not regress anything.
But there are some places that still need rtx_costs, yes.
Do you have anything in particular in mind? PRs welcome!
Segher
Nothing specific. I have vague recollections of a few places that
generated quite complex RTL expressions and then expected rtx_costs to
do the decomposition into the cost of the sequence for computing that.
Perhaps the mul synthesis code was like that, but I'm probably
misremembering it.
Certainly an API where you *know* the RTL is a legal insn and not
something made up by the mid-end would be a real step forward - I think
there are still places in the mid-end that generate (PLUS:QI ...), for
example, and simple expect rtx_cost to return a useful answer even on a
RISC target with no such instruction.
R.
