Jeff Law <l...@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