On 09/10/2015 11:11 PM, Jeff Law wrote:
I think that's probably what James is most interested in getting some
ideas around -- the cost model.
I think the fundamental problem is BRANCH_COST isn't actually relative
to anything other than the default value of "1". It doesn't directly
correspond to COSTS_N_INSNS or anything else. So while using
COSTS_N_INSNS (BRANCH_COST)) would seem to make sense, it actually
doesn't. It's not even clear how a value of 10 relates to a value of 1
other than it's more expensive.
ifcvt (and others) comparing to magic #s is more than a bit lame. But
with BRANCH_COST having no meaning relative to anything else I can see
why Richard did things that way.
In an ideal world we'd find some mapping from BRANCH_COST that relates
to CONST_N_INSNS. I suspect a simple mapping doesn't necessarily exist
and we'll likely regress targets with any simplistic mapping. But maybe
now is the time to address that fundamental problem and deal with the
fallout.
I think the right approach if we want to fix this is a new
branch_cost_ninsns target hook (maybe with arguments taken_percentage,
predictability), and gradually move everything to use that instead of
BRANCH_COST.
Bernd
