This is the mail archive of the mailing list for the glibc 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: [PATCH] always inline alloc_perturb.

On Fri, Dec 12, 2014 at 09:34:17AM -0500, David Miller wrote:
> From: OndÅej BÃlka <>
> Date: Fri, 12 Dec 2014 12:18:56 +0100
> > Compiler uses simple heuristics for inlining, not magic. It pretty often
> > refuses to inline functions that after inlining he could say delete half
> > code as dead. Reason why it should be inlined is simple, unlikely branch
> > is much cheaper than function call.
> This only tells me that the compiler should become more sophisticated
> over time, not that we should forver assume it can't do a good job.
> If we continue to hand inline things, there is zero incentive to
> make the compiler smarter about it.

And is worse performance in next ten years until that issues are fixed

To get smarter compiler you need to fill bugs where inliner misbehaves,
just promising that we will not inline and asking to improve gcc will
not help much.

For start you should make gathering profile information in libc
possible. Without that no compiler can make good decision as there are
workloads where he should inline and in other workload he shouldn't.

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