This is the mail archive of the
mailing list for the GCC project.
Re: [patch] RFC: Hook for insn costs?
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- Cc: Jeff Law <law at redhat dot com>, Richard Henderson <rth at twiddle dot net>, Richard Biener <richard dot guenther at gmail dot com>, Georg-Johann Lay <avr at gjlay dot de>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 2 Aug 2017 15:26:56 -0500
- Subject: Re: [patch] RFC: Hook for insn costs?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20170715225119.GA13471@gate.crashing.org> <CAFiYyc21ALx=eSbOUMNo+B-MqMutVRgUfkpmi_7v1KkNs4kF3A@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <email@example.com>
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.