Hi!
I'm looking at improving inlining heuristics at the moment,
especially by questioning the estimate_num_insns. All uses
of that function assume it to return a size cost, not a computation
cost - is that correct? If so, why do we penaltize f.i. EXACT_DIV_EXPR
compared to MULT_EXPR?
Also, for the simple function
double foo1(double x)
{
return x;
}
we return 4 as a cost, because we have
double tmp = x;
return tmp;
and count the move cost (MODIFY_EXPR) twice. We could fix this
by not walking (i.e. ignoring) RETURN_EXPR.
Also, INSNS_PER_CALL is rather high (10) - what is this choice
based on? Wouldn't it be better to at least make it proportional
to the argument chain length? Or even more advanced to the move
cost of the arguments?
Finally, is there a set of testcases that can be used as a metric
on wether improvements are improvements?
Thanks,
Richard.
--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
