On Wed, Aug 02, 2017 at 08:34:20PM +0100, Richard Earnshaw wrote: > >> 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.
I am doing this for rs6000 now, and it is totally practical. > 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). Yes, but in many cases a pass wants to create valid insns anyway. I changed combine to always use insn_cost (instead of pattern_cost, what used to be named insn_rtx_cost). Implementation of this (for rs6000) is much simpler: most insns just cost COSTS_N_INSNS (N) with N the number of machine insns generated, and most others can easily use a new attribute "cost", which for example can use the existing rs6000_cost structure (that gives costs for various cpu models). > 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. We already use the same in the rtx_costs hook; it is quite a bit nicer to have it in the machine description itself. I am dumping out the "old" cost and "new" cost whenever they differ. It turns out that more than half of the differences are where the *old* cost was bad! > 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. I currently handle this directly in the insn_cost hook; it could also be handled in the md files. Of course this problem is easy for rs6000 because Power is purely a load-store architecture. Segher
