Bug 23830 - inline analysis improvements
inline analysis improvements
Status: NEW
Product: gcc
Classification: Unclassified
Component: middle-end
unknown
: P2 enhancement
: ---
Assigned To: Not yet assigned to anyone
: missed-optimization
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-12 04:47 UTC by Atif Hussain
Modified: 2012-03-25 10:02 UTC (History)
4 users (show)

See Also:
Host: frontend
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-24 19:54:29


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Atif Hussain 2005-09-12 04:47:09 UTC
subj: For functions specified inline, decision to inline them should be based on
inlined code size instead of un-inlined function length.

Here is a simple snippet of a larger complex.

inline int changePrecision(int x, int x_prec, int y_prec) {
if (y_prec>x_prec) return (x<<(y_prec-x_prec));
else
if (y_prec<x_prec) return (x>>(x_prec-y_prec));
else
return k;
}
which is intended to be called with constants x_prec & y_prec.
This code though assigned inline (it would be 0 or 1 cycles) is 
first created into a function, observed to be long enough, and not inlined.
Comment 1 Andrew Pinski 2005-09-12 05:01:00 UTC
For 4.1 we do have IPA based constant propagation which basically implements what you want.
Comment 2 Andrew Pinski 2005-09-13 20:15:43 UTC
Confirmed. After IPA constant prop and before inlining, we need early optimizations, like DCE and 
constant prop.  But that is it.
Comment 3 Andrew Pinski 2011-07-18 22:19:34 UTC
I think this might already be fixed in either 4.6.0 or on the trunk.
Comment 4 Jan Hubicka 2012-03-23 15:38:32 UTC
Inline predicates handle this case for both ipa-constant propagation and inliner.
We will now work out that y-prec-x_prec and x_prec-y_prec will be constant and that the conditionals will be decided at compile time.

We now inline ChangePrecision at -Os.
We however still won't get that y_prec>x_prec can be resolved at compile time. Only tests comparing with constants.

 BB 2 predicate:(true)
  if (y_prec_2(D) > x_prec_3(D))
                freq:1.00 size:  2 time:  2
                Accounting size:2.00, time:2.00 on new predicate:(op2 changed || op1 changed)

 BB 3 predicate:(true)
  D.1717_4 = y_prec_2(D) - x_prec_3(D);
                freq:0.39 size:  1 time:  1
                Accounting size:1.00, time:0.39 on predicate:(op2 changed || op1 changed)
  D.1716_6 = x_5(D) << D.1717_4;
                freq:0.39 size:  1 time:  1
                Accounting size:1.00, time:0.39 on new predicate:(op2 changed || op1 changed || op0 changed)

 BB 4 predicate:(true)
  if (y_prec_2(D) < x_prec_3(D))
                freq:0.61 size:  2 time:  2
                Accounting size:2.00, time:1.22 on predicate:(op2 changed || op1 changed)

 BB 5 predicate:(true)
  D.1720_7 = x_prec_3(D) - y_prec_2(D);
                freq:0.37 size:  1 time:  1
                Accounting size:1.00, time:0.37 on predicate:(op2 changed || op1 changed)
  D.1716_8 = x_5(D) >> D.1720_7;
                freq:0.37 size:  1 time:  1
                Accounting size:1.00, time:0.37 on predicate:(op2 changed || op1 changed || op0 changed)

 BB 6 predicate:(true)
  return D.1716_1;
                freq:1.00 size:  1 time:  2
                Will be eliminated by inlining
                Accounting size:1.00, time:2.00 on predicate:(not inlined)

....

Considering changePrecision.constprop.0 with 5 size
 to be inlined into t in t.c:12
 Estimated growth after inlined into all is -8 insns.
 Estimated badness is -1073741827, frequency 1.00.
    Badness calculation for t -> changePrecision.constprop.0
      size growth -3, time growth -12
      -1073741827: Growth -3 <= 0
                Accounting size:2.00, time:0.76 on new predicate:(op0 changed)