[PATCH 0/5] RFC, WIP: RTL cost improvements

Richard Sandiford richard.sandiford@linaro.org
Wed Aug 9 16:19:00 GMT 2017


Jeff Law <law@redhat.com> writes:
> 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.

COSTS_N_INSNS lets you add sub-instruction costs, so that you can
slightly prefer faster N-byte instructions to slower N-byte instructions.

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

I think even the complex operands can be handled by attributes: you can
have one enum attribute that describes the complexity, perhaps with the
default value calling out to a C function if necessary, and then make
the default value of the cost attribute switch on that enum attribute.

Thanks,
Richard



More information about the Gcc-patches mailing list