On Thu, 24 Feb 2005 20:05:37 +0100, Richard Guenther
<rguenth@tat.physik.uni-tuebingen.de> 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.