On Thu, 24 Feb 2005 20:05:37 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> Jan Hubicka wrote:
>
> >>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 work, yes. I was also thinking about ignoring MODIFY_EXPR
> > for var = var as those likely gets propagated later.
>
> This looks like a good idea. In fact going even further and ignoring
> all assigns to DECL_IGNORED_P allows us to have the same size estimates
> for all functions down the inlining chain for
Note that this behavior also more closely matches the counting of gcc 3.4
that has a cost of zero for
inline int foo(void) { return 0; }
and a cost of one for
int bar(void) { return foo(); }
while with the patch we have zero for foo and zero for bar.
For
inline void foo(double *x) { *x = 1.0; }
double y; void bar(void) { foo(&y); }
3.4 has 3 and 5 after inlining, with the patch we get 2 and 2.
For
inline double foo(double x) { return x*x; }
inline double foo1(double x) { return foo(x); }
double foo2(double x) { return foo1(x); }
3.4 has 1, 2 and 3, with the patch we get 1, 1 and 1.
For a random collection of C files out of scimark2 we get
3.4 4.0 4.0 patched
SOR 54, 10 125, 26 63, 14
FFT 44, 11, 200, 59 65, 10, 406, 111 51, 10, 243, 71
so apart from a constant factor 4.0 patched goes back to 3.4
behavior (at least it doesn't show weird numbers). Given that
we didn't change inlining limits between 3.4 and 4.0 that
looks better anyway. And of course the testcases above show
we are better in removing abstraction penalty.
Richard.
