On Fri, Sep 11, 2015 at 10:53:13AM +0200, Bernd Schmidt wrote: > 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.
Perhaps providing backends with the entire if-then-else block along with the above mentioned information being if converted may be another approach, it allows the backends to analyse what cases are good to if-convert as per the ISA or micro-architecture and what aren't. regards Ramana
