On Thu, Nov 21, 2019 at 08:12:05PM -0500, Paul Koning wrote: > > On Nov 21, 2019, at 7:42 PM, Segher Boessenkool > > <seg...@kernel.crashing.org> wrote: > > > > ... > > Maybe i386 should implement the insn_cost hook as well? For most targets > > that is a lot simpler to get right than rtx_cost, but allowing memory in > > many insns and all the different insn lengths complicates matters. At > > least insn_cost isn't inside-out, that should make it easier to deal with > > already. > > Yes, rtx_cost is a pain to write and understand. I looked at insn_cost in > the past but was told, or got the impression somehow, that it is at the > moment a partial solution and rtx_cost is still needed to complete the cost > picture. > > Is that incorrect, or no longer accurate? I would like to dump rtx_cost in > my target if that is now indeed a valid thing to do.
Some things still want the rtx_cost of non-insns. CSE does this, as does expand (for figuring out the multiplication strategy to use, for one thing), and then there are set_src_cost and set_rtx_cost (which are probably not hard to fix, for the cases where there *is* an insn for doing things). With rtx_cost you need to estimate the cost of arbitrary RTL expressions, whether that means anything for the machine or not. This does not make terribly much sense, but changing the compiler her without regressing things isn't trivial. Segher
