On Feb 24, 2005 01:58 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I'm looking at improving inlining heuristics at the moment,
> especially by questioning the estimate_num_insns.
Good. There is lots of room for improvement there.
> All uses
> of that function assume it to return a size cost, not a computation
> cost - is that correct?
Yes.
> If so, why do we penaltize f.i. EXACT_DIV_EXPR
> compared to MULT_EXPR?
Dunno. Because divide usually results in more insns per tree?
> 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.
That would be a good idea if all estimate_num_insns ever sees
is GIMPLE. Are you sure that is the case (I think it is, but
I'm not sure).
> Also, INSNS_PER_CALL is rather high (10) - what is this choice
> based on?
History. That's what it was in the old heuristics.
> 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?
That is what the RTL inliner used to do. The problem now is that
you don't know what gets passes in a register and what is passed
on the stack.
> Finally, is there a set of testcases that can be used as a metric
> on wether improvements are improvements?
What I did in early 2003 was to add a mini-pass at the start of
rest_of_compilation that just counted the number of real insns
created for the current_function_decl, i.e. something like
int num_insn = 0; rtx insn;
for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
num_insn++;
and then compare the result with the estimate of the tree inliner.
The results were quite discouraging at the time, which is why
Honza rewrote the size estimate. No idea how well or poor we do
today ;-)
Gr.
Steven
