This is the mail archive of the gcc@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]

Re: RFC: Inlines, LTO and GCC


On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
> This last point is crucial.  I haven't looked at the code in question,
> but one point to check is how the functions are called.  If they are
> often called with constant values, then they may be very much simplified
> due to constant propagation.  Secondly, if a function is inlined, the
> compiler has full knowledge of the effects of the function "call" and
> can thus optimise better (keeping data in registers over the "call",
> shuffling around loads and stores, etc.).  Finally, if the functions are
> called in loops or other time-critical code, it can be worth spending
> more code section space for a faster result (but sometimes smaller code
> is faster due to caches, branch prediction buffers, etc.).
> 
> The ideal situation is that LTO figures this out for you, and the code

At least until LTO keeps to end up with unusable or hardly usable debug
info, effectively requiring LTO for good compiler performance is a
non-starter.  And, the inliner we have is not dumb, if it sees an inline
function, but it is too large, it will usually not inline it.
So, rather than counting the lines of inline functions in headers, IMHO it
is better to look at inliner's decisions about those functions, if it
never inlines them, then supposedly moving them out of line is reasonable.

	Jakub


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