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.
I think it is simpler if the insn_cost hook implementation itself calls
rtx_cost (or pattern_cost etc.) where it wants to.
> > 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.
Yep. Most of this can be handled inside just some platform-specific
cost attribute(s).
> 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.
Yes, I don't know if the new hook will make life much simpler for highly
CISC, or irregular architectures. So far it looks very promising for
"RISC", more regular architectures. Anything that doesn't want to
implement it can just use the old way of things.
> One could also walk the pattern to count the number of mems, at least for a
> given subset of insn types.
Right.
Segher
