This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Inlining and estimate_num_insns


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]