[PATCH] [4.0] Fix performance regressions due to inlining

[Paul Schlie]

> From: Steven Bosscher <stevenb@suse.de>
> On Friday 04 March 2005 20:01, Paul Schlie wrote:
>>> Steven Bosscher writes:
>>> 
>>> Say you have a tree like this:
>>> 
>>> <modify_expr <var_decl "a"> <plus_expr <var_decl "b"> <constant C>>
>>> 
>>> i.e. "a = b + C;".  In the existing heuristics we count 1 for the
>>> plus_expr and 1 for the store to "a".  But that assignment to "a"
>>> is free on almost any sane target if "a" is a GIMPLE register (and
>>> "a" indeed ends up in a register eventually).  With Richard G.'s
>>> new heuristics, the store to "a" would be free, and I think that
>>> is not a hack but a good idea.
>> 
>> Unfortunately wouldn't this potentially seriously underestimate the
>> cost/size on 2-operand machines when "b"'s value needs to be preserved;
>> resulting in even greater code inlining on targets least likely to benefit
>> from it?
> 
> I don't see how.

- although I may misunderstand, on a typical 3-operand machine:

    add r<a> r<b> c<> ; therefore a cost estimate of 1 seems good.

  but on a 2-operand machine, typical of lower-end arm, mips, etc.:

    mov r<a> c<c>  ; being typical, a cost of 2 seems reasonable
    add r<a> r<b>  ; as it stands today.
 
  But if the cost/size is underestimated, it would seem to imply that
  more code than likely intended may be in-lined; wouldn't it?
  
>> (not to mention what the cost of C, may more accurately be in various
>> circumstances)
> 
> We did not take that into account before either.

- understood (just noting that for 2-operand machines, reducing the
  present heuristic estimate for the above from 2 to 1, may not be good).

> You're more than welcome to fix that of course.

- maybe in time (still in the process of figuring out which end is up)