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.
> 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.
r~
