Segher Boessenkool <seg...@kernel.crashing.org> writes:
> On Wed, Aug 09, 2017 at 09:56:31AM -0600, Jeff Law wrote:
>> On 08/08/2017 10:54 AM, Richard Sandiford wrote:
>> > 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.
> "length" is (by necessity) pessimistic, cost doesn't have to be. Not
> that it will make much difference as far as I can see.
>> > 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 :-)
> I was thinking I could have "cost" (for rs6000) have a default value
> that looks at "type". This can then optimise things a little bit.
> But, we probably still need the "function" version as well, for the more
> complex cases. Simpler targets can do this of course.
>> > 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.
> We need it, for example, to properly cost the various define_insn_and_split
> (for which "type" is only an approximation, and is woefully inadequate
> for determining cost).
But define_insn_and_splits could override the cost explicitly if they
need to. That seems neater than testing for them in C.
>> > I can't really see
>> > what a C function would give over keeping the costs with the instruction
>> > definitions.
> There are many insn patterns that can share the cost computation.
>> 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.
> Making this a hook is by far the most flexible.
Maybe, but if so, that would probably also have been true for "enabled"
and "length". We gained something by not making them hooks.
> One place where operands are nasty on rs6000 is subregs of float. Those
> are used all over the place, and they aren't turned into (expensive!)
> insns until LRA. In the insn patterns they look just like a SI (or DI)
> reg :-(
> Another example is unaligned MEMs, which can be very expensive, much
> more expensive than aligned MEMs.
...thanks, I agree these are convincing.
> The common theme is that we care most about cost in the not-so-happy
> cases, and those are often not easy to express in attributes.