This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

optimization/10679: [3.3/3.4] --param min-inline-insns not honoured


>Number:         10679
>Category:       optimization
>Synopsis:       [3.3/3.4] --param min-inline-insns not honoured
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Thu May 08 12:16:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Richard Guenther
>Release:        g++-3.3 (GCC) 3.3 20030505 (prerelease), g++-3.4 (GCC) 3.4 20030505 (experimental)
>Organization:
>Environment:
ia32 gnu-linux
>Description:
If specifying --param min-inline-insns one expects from the manual all functions with size <= min-inline-insns to be inlined. This is not the case if inlining repeatedly into a large function as can be seen from comments/code in tree-inline.c:inlinable_function_p (line 1003-)

This severly pessimizes scientific code based on the POOMA library, where inlining of small function is vitally important. After applying the attached patch, >30% performance can be gained and the --param min-inline-insns behaves as documented.

No testcase, the defect can be pinpointed in the gcc source. A testcase would look like

inline void bar(void) { }
void foo(void)
{
    bar(); bar(); bar(); /* repeat 10000 times... */
}

at a certain point, bar()s would be no longer inlined and
the resulting foo() would not be empty.
>How-To-Repeat:
Repeatedly inline a small function into a large one.
>Fix:
Apply the attached patch.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="tree-inline-patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tree-inline-patch"

SW5kZXg6IHRyZWUtaW5saW5lLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9nY2MvZ2NjL2dj
Yy90cmVlLWlubGluZS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjM4LjIuOApkaWZmIC11IC11
IC1yMS4zOC4yLjggdHJlZS1pbmxpbmUuYwotLS0gdHJlZS1pbmxpbmUuYwkyIE1heSAyMDAzIDE5
OjUyOjAxIC0wMDAwCTEuMzguMi44CisrKyB0cmVlLWlubGluZS5jCTggTWF5IDIwMDMgMTI6MDk6
MTkgLTAwMDAKQEAgLTEwMDcsMTcgKzEwMDcsMTEgQEAKICAgICB7CiAgICAgICBpbnQgc3VtX2lu
c25zID0gKGlkID8gaWQtPmlubGluZWRfc3RtdHMgOiAwKSAqIElOU05TX1BFUl9TVE1UCiAJCSAg
ICAgKyBjdXJyZm5faW5zbnM7Ci0gICAgICAvKiBJbiB0aGUgZXh0cmVtZSBjYXNlIHRoYXQgd2Ug
aGF2ZSBleGNlZWRlZCB0aGUgcmVjdXJzaXZlIGlubGluaW5nCi0gICAgICAgICBsaW1pdCBieSBh
IGh1Z2UgZmFjdG9yICgxMjgpLCB3ZSBqdXN0IHNheSBuby4gU2hvdWxkIG5vdCBoYXBwZW4KLSAg
ICAgICAgIGluIHJlYWwgbGlmZS4gICovCi0gICAgICBpZiAoc3VtX2luc25zID4gTUFYX0lOTElO
RV9JTlNOUyAqIDEyOCkKLQkgaW5saW5hYmxlID0gMDsKLSAgICAgIC8qIElmIHdlIGRpZCBub3Qg
aGl0IHRoZSBleHRyZW1lIGxpbWl0LCB3ZSB1c2UgYSBsaW5lYXIgZnVuY3Rpb24KLSAgICAgICAg
IHdpdGggc2xvcGUgLTEvTUFYX0lOTElORV9TTE9QRSB0byBleGNlZWRpbmdseSBkZWNyZWFzZSB0
aGUKLSAgICAgICAgIGFsbG93YWJsZSBzaXplLiBXZSBhbHdheXMgYWxsb3cgYSBzaXplIG9mIE1J
Tl9JTkxJTkVfSU5TTlMKLSAgICAgICAgIHRob3VnaC4gICovCi0gICAgICBlbHNlIGlmICgoc3Vt
X2luc25zID4gTUFYX0lOTElORV9JTlNOUykKLQkgICAgICAgJiYgKGN1cnJmbl9pbnNucyA+IE1J
Tl9JTkxJTkVfSU5TTlMpKQorICAgICAgLyogV2UgdXNlIGEgbGluZWFyIGZ1bmN0aW9uIHdpdGgg
c2xvcGUgLTEvTUFYX0lOTElORV9TTE9QRSB0bworICAgICAgICAgZXhjZWVkaW5nbHkgZGVjcmVh
c2UgdGhlIGFsbG93YWJsZSBzaXplLgorICAgICAgICAgV2UgYWx3YXlzIGFsbG93IGEgc2l6ZSBv
ZiBNSU5fSU5MSU5FX0lOU05TIHRob3VnaC4gICovCisgICAgICBpZiAoKHN1bV9pbnNucyA+IE1B
WF9JTkxJTkVfSU5TTlMpCisJICAmJiAoY3VycmZuX2luc25zID4gTUlOX0lOTElORV9JTlNOUykp
CiAJewogCSAgaW50IG1heF9jdXJyID0gTUFYX0lOTElORV9JTlNOU19TSU5HTEUKIAkJCS0gKHN1
bV9pbnNucyAtIE1BWF9JTkxJTkVfSU5TTlMpIC8gTUFYX0lOTElORV9TTE9QRTsK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]