On Mon, Oct 21, 2019 at 05:06:20PM +0100, Richard Earnshaw (lists) wrote: > On 21/10/2019 16:46, Segher Boessenkool wrote: > >>>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! > > 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.
Yeah, and there are a few other (less important) places that do not have anything like an insn. > 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 - That is exactly what insn_cost is. Well, it takes an rtx_insn *, even. > 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. Yup. CSE still uses rtx_cost directly. avoid_expensive_constant does, too, and some other optabs stuff. Less important are the uses in dojump, expr, expmed (there is your "mult"), But the really big ones left are set_src_cost and set_rtx_cost I think. Segher
