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.
Thanks,
James
