This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Simplify perturb_byte logic.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Fri, 13 Dec 2013 09:45:17 +0100
- Subject: Re: [PATCH] Simplify perturb_byte logic.
- Authentication-results: sourceware.org; auth=none
- References: <20131209141613 dot GA15247 at domone dot podge> <52A5E9E3 dot 4020505 at cs dot ucla dot edu> <20131209162724 dot GA30871 at domone dot podge> <20131211233843 dot BD74A7442B at topped-with-meat dot com> <52A8FCA7 dot 1080001 at cs dot ucla dot edu> <20131212002624 dot GA3888 at domone dot podge> <20131212030428 dot A5D9174428 at topped-with-meat dot com>
On Wed, Dec 11, 2013 at 07:04:28PM -0800, Roland McGrath wrote:
> > Should be always_inline, for macros converted to function otherwise we
> > could degrade performance.
>
> Or we could improve performance because code size actually matters more and
> the second-guessing of the compiler hasn't been helping in years (if ever)...
Yes if gcc could actually improve size by that. Size without always_inline is
-rwxr-x--- 1 ondra stu 10710437 Dec 13 09:01 libc.so
And adding always_inline improves this to
-rwxr-x--- 1 ondra stu 10710167 Dec 13 09:07 libc.so
And if compiler could accurately compute impact of inlining, not just
function size * estimated path probability.
For function in question a code is
if (__glibc_unlikely (perturb_byte))
memset (p, perturb_byte ^ 0xff, n);
Which is around 5 bytes (compare instruction and jump) in fast path.
Always adding call which is already 5 bytes and much more by additional
register spills on fast path is is simply bad idea (and gcc design does
not allow estimate how many registers will get spilled.)