On 26/07/17 18:54, Jeff Law wrote: > On 07/17/2017 02:35 PM, Richard Henderson wrote: >> On 07/17/2017 12:20 AM, Richard Biener wrote: >>> On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool >>>> Now what should it take as input? An rtx_insn, or just the pattern >>>> (as insn_rtx_cost does)? >>> >>> Is there any useful info on the other operands of an rtx_insn? If not >>> then passing in the pattern (a rtx) might be somewhat more flexible. >>> Of course it's then way easier to confuse rtx_cost and insn_cost ... >> >> A lot of really complex by-hand pattern matching goes away if you know >> the instruction is valid, and you can look up an insn attribute. That >> suggests passing the insn and not the PATTERN. > Good point. In fact, it opens the possibility that costing could be > attached to the insn itself as just another attribute if it made sense > for the target to describe costing in that manner. > > Jeff >
I'm not sure if that's a good or a bad thing. Currently the mid-end depends on some rtx constructs having sensible costs even if there's no rtl pattern to match them (IIRC plus:QI is one such construct - RISC type machines usually lack such an instruction). Also, costs tend to be micro-architecture specific so attaching costs directly to patterns would be extremely painful, adding support would require touching the entirety of the MD files. The best bet would be a level of indirection from the patterns to cost tables, much like scheduler attributes. But that still leaves the issue of what to do with the cost of MEM vs REG operands - in a pattern they may both be matched by general_operand but the cost of each is quite distinct and the normal attributes system probably won't (maybe can't) disambiguate the sub-types until after register allocation. R.
