On Thu, 24 Feb 2005, Steven Bosscher wrote:
> 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?
Well, I don't know - but ia32 fdiv and fmul are certainly of the
same size ;) Of course for f.i. ia64 inlined FP divide this is
not true, which asks for target dependent size estimates. So,
pragmatically we should rather count tree nodes than trying to
second-guess what the target-specific cost is.
> > 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 for GENERIC, at least for what the C and C++ frontends are
generating. What is discouraging at the moment is that we do
not remove the "abstraction penalty" of
inline int foo1(void)
{
return 0;
}
int foo(void)
{
return foo1();
}
currently we have a cost of 2 for foo1 and a cost of 5 for foo with
foo1 inlined. With the RETURN_EXPR ignore we get to 1 for foo1 and
2 for foo with inlined foo1. I'll think about how to get that down
to 1.
Richard.
--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
