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.
This really looks like good compromise until we will be able to optimize code before inlining better (this is what I am shooting for in tree-profiling but we are not quite there yet) and even after that perhaps assignments to temporaries should be considered free, since we count cost of the operation later anyway. The patch is OK for mainline
You mean the patch at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01571.html
I guess?
and assuming that there will be no negative hops in SPEC scores on Diego's and Andrea's testers, I would like to see it in 4.0 too since this counts as code quality regression, but this is Mark's call I guess.
Mark? I would say that there is little risk in this patch corectness wise, might have negative effect on compilation times since we re-start inlining more like we did in old days.
I'll apply the patch to mainline tomorrow and post some compile time numbers as Steven suggested.
Richard.
