Re: [PATCH] Reorganize rs6000_rtx_costs

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 2 Jul 2004, Dale Johannesen wrote:
> As long as you're working with the rtx_costs stuff, have you thought
> about a new mechanism that would handle modern processors better?

I agree modern CPUs require a more complex performance model than
just rtx_cost.  And indeed the DFA-based scheduling passes already
encode this latency, issue-rate, resource utilization information.
I suspect that longer term, the solution is to enhance our scheduling
passes, with combine/peephole2-like functionality that decides that
if no "available" instruction can be issued because of issue/resource
constraints, is there an alternative representation/decomposition of
the same operation that can be.

The early middle-end, however, will still need the current "rtx_cost"
functionality:  that should return the pattern's latency or size
reflecting the GCC's current usage.  This is a reasonable heuristic
metric to optimize against until the compiler has a more accurate
representation of the instruction stream after register allocation
and/or scheduling.

Indeed, I expect a well parameterized rtx_cost function to be able to
act as the kernel to a new tree_expr_cost, that'll be able to provide
approximate target information to tree-ssa, LNO and constant folding
at the tree-level.  Clearly, a fine-grained performance model would
be overkill this early, but the vectorizers and friends could benefit
from knowing that operation costs of "long long"s relative to "ints".


Reasonable short-term goals are to (i) provide reasonable "latency/size"
rtx_costs, as these values are poor even for the best maintained
backends and (ii) continue the efforts to transition the remaining
backends to use the new DFA pipeline models.  Its good to be thinking
about the future, but until backends make the best use of the existing
GCC infrastructure (RTL prologs, peephole2, etc...), quantifying the
potential benefits of "next generation" GCC passes is more difficult.
There's still plenty of pre-tree-ssa cruft that needs to be eliminated
from the compiler, to avoid GCC becoming a graveyard of old code.

Roger
--