This is the mail archive of the
mailing list for the GCC project.
Re: [patch] RFC: Hook for insn costs?
- From: Richard Henderson <rth at twiddle dot net>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, Jeff Law <law at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Georg-Johann Lay <avr at gjlay dot de>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 2 Aug 2017 12:56:58 -0700
- 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 08/02/2017 12:34 PM, Richard Earnshaw wrote:
> 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).
I hadn't considered this... but there are several possible workarounds.
The simplest of which is to fall back to using rtx_cost if the insn_cost hook
returns a failure indication, e.g. -1.
> 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.
I was never thinking of adding costs directly to the md files, but rather
structuring the insn_cost hook like
if (recog_memoized (insn) < 0)
switch (get_attr_type (insn))
return COSTS_N_INSNS (1);
etc. This would be especially important when it comes costing for simd-type
insns. Matching many of those any other way would be fraught with peril.
> 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.
Pre-reload we'll probably have a pseudo and assume a register operand, or have
an unambiguous memory. I don't think that's really a problem. We're producing
a cost estimate based on what we are given at that moment.
It does make x86 more complex than more RISC-ier targets, but still not
impossible. There is at least a "memory" attribute with which one could adjust
the base cost selected by the "type" attribute.
One could also walk the pattern to count the number of mems, at least for a
given subset of insn types.