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