> 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
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.
Thanks!
Honza
>
> Richard.
