This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] always inline alloc_perturb.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: David Miller <davem at davemloft dot net>
- Cc: roland at hack dot frob dot com, libc-alpha at sourceware dot org
- Date: Fri, 12 Dec 2014 16:50:51 +0100
- Subject: Re: [PATCH] always inline alloc_perturb.
- Authentication-results: sourceware.org; auth=none
- References: <20141211203625 dot GA7490 at domone> <20141211205209 dot 6905E2C3ACD at topped-with-meat dot com> <20141212111856 dot GA8768 at domone> <20141212 dot 093417 dot 507023024907812119 dot davem at davemloft dot net>
On Fri, Dec 12, 2014 at 09:34:17AM -0500, David Miller wrote:
> From: OndÅej BÃlka <neleai@seznam.cz>
> 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
acceptable?
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.