This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 0/5] RFC, WIP: RTL cost improvements
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).
> > 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.
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.
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.
Segher