On 08/08/2017 10:54 AM, Richard Sandiford wrote:
>>> For speed cost I primarily use "type", modified by the number of machine
>>> insns a pattern generates (quite a few are split); and I get the number
>>> of machine insns just from "length" again, which for rs6000 is easy and
>>> correct in most cases.  Some other targets may need something else.
>>> I also have an attribute "cost" that can be used to override the
>>> default calculation; that seems useful to standardise on.  I've pondered
>>> a "cost_adjust" that will be added to the calculated cost instead, but
>>> it hasn't been useful so far.
>> Let's go ahead and "reserve" cost and cost_adjust for this purpose.  If
>> we find that cost_adjust isn't actually necessary, then so be it, it's
>> not a big deal to me.
> I was thinking we should have separate attributes for size and speed
> from the outset.   How about size_cost and speed_cost?  It'd be up
> to the target to decide whether to define them as the sums of various
> sub-attributes (like it's the target's decision how to break "enabled"
> down).
But size_cost should be equivalent to the already standardized length
attribute.  So I'm struggling to see a need for that.

Again, no strong opinions on how to structure the speed cost other than
to standardize a name.

> The advantage of doing it all in attributes is that the generator might
> be able to help optimise the process of checking for costs.  No promises
> though :-)

> TBH I think we should start with the attributes as well-defined names
> and only add the hook if we find we still need it.  I can't really see
> what a C function would give over keeping the costs with the instruction
> definitions.
I'd think the C function would mostly be helpful on a cisc target where
operands are potentially complex.   But I don't feel strongly enough
about it to argue -- I'm happy to go with consensus and fault in
adjustments if we need them.


Reply via email to