This is the mail archive of the
mailing list for the GCC project.
Inlining and estimate_num_insns
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 24 Feb 2005 13:58:07 +0100 (CET)
- Subject: Inlining and estimate_num_insns
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)
we return 4 as a cost, because we have
double tmp = x;
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?
Richard Guenther <richard dot guenther at uni-tuebingen dot de>