This is the mail archive of the
mailing list for the GCC project.
Re: [patch] RFC: Hook for insn costs?
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: 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>, Georg-Johann Lay <avr at gjlay dot de>, GCC Development <gcc at gcc dot gnu dot org>, <nd at arm dot com>
- Date: Thu, 3 Aug 2017 11:01:47 +0100
- Subject: Re: [patch] RFC: Hook for insn costs?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 188.8.131.52) smtp.mailfrom=arm.com; gjlay.de; dkim=none (message not signed) header.d=none;gjlay.de; dmarc=bestguesspass action=none header.from=arm.com;
- Nodisclaimer: True
- 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> <firstname.lastname@example.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Wed, Aug 02, 2017 at 12:56:58PM -0700, Richard Henderson wrote:
> 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)
> return -1;
> switch (get_attr_type (insn))
> case TYPE_iadd:
> case TYPE_ilog:
> case TYPE_mvi:
> return COSTS_N_INSNS (1);
> case TYPE_fadd:
> return cost_data->fp_add;
> 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.
I tried prototyping something like this for AArch64 a while back - it
feels like the only sensible, scalable and maintainable way to rationalise
the costs code. Anything else drifts from the md file over time, and is
a tangled mess of spaghetti code to implement a poor-quality recog clone.
I ran in to exactly the problem Richard Earnshaw mentions above - too
many partial rtx fragments came in that I couldn't recognise. The points
in the compilation pipeline where I could receive an RTX to cost meant that
I could get be asked for costs before recog was correctly initialised.
I think a clean hook which operated in this way would be a great step
forward for the RTX costs.