This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 81980 - GCC inline limit is very bad
GCC inline limit is very bad
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc (Show other bugs)
1.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-15 18:20 EST by Luca Barbieri
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-03 07:59:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Sample code (484 bytes, text/plain)
2003-01-15 18:26 EST, Luca Barbieri
no flags Details

  None (edit)
Description Luca Barbieri 2003-01-15 18:20:23 EST
Description of Problem:
GCC apparently disregards the programmer use of the "inline" keyword when the
function is larger than a certain threshold, potentially causing very poor code
generation.

Furthermore it appears to do so based on the size of the function rather than
the size of the optimized code that would be generated by inlining it, which
makes the problem much worse.

In particular some functions (e.g. Linux memcpy and friends) check whether
parameters are constant and if so do a long list of checks on the parameters,
sure that they will be optimized away: GCC screws this up horribly and
transforms a clever programmer optimization in a huge slowdown.

There also functions that are very long and cannot be splitted in separate
"physical" functions for performance reasons, but are instead splitted in, maybe
very long, inline functions that are used once: GCC also screws this up horribly.


IMHO this "feature" should be removed, and GCC should always honor the
programmer's choice, which he must make correctly anyway since other compilers
might not correct it.

If that is not possible, the limit should at least be increased.


The problem can be worked around using this code:
#if (__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ >= 2))
#if !defined(__cplusplus) && defined(__OPTIMIZE__)
#define inline inline __attribute__((always_inline))
#endif
#endif


Version-Release number of selected component (if applicable):
gcc-3.2.1-2

How Reproducible:
Every time.

Steps to Reproduce:
1. Compile the attached code with "-O2 -S" for x86code; then add the
"-finline-limit=1000000" option and compare the two assembly listings.

-or-

1. Compile Linux for x86 with no special inline limit settings and do an `nm
vmlinux|grep __constant`. These functions should have been inlined.
Comment 1 Luca Barbieri 2003-01-15 18:26:27 EST
Created attachment 89396 [details]
Sample code
Comment 2 Richard Henderson 2004-10-03 07:59:16 EDT
Inline heuristics rewritten for gcc 3.4.  Things are significantly
better there.  Debugging output (-dU) shows

Considering generic_fls with 38 insns
 Estimated growth is -10 insns.
 Inlined into test which now has 51 insns.
 Inlined 1 times for a net change of -10 insns.

Note You need to log in before you can comment on or make changes to this bug.