This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [WIP] Remove nested function in elf/dl-lookup.c? (Nested functions considered harmful?)
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 16 Dec 2013 11:12:09 -0500
- Subject: Re: [WIP] Remove nested function in elf/dl-lookup.c? (Nested functions considered harmful?)
- Authentication-results: sourceware.org; auth=none
- References: <52AC8036 dot 7000300 at redhat dot com> <20131216044129 dot GA18419 at spoyarek dot pnq dot redhat dot com> <52AF0EEC dot 3000508 at redhat dot com> <20131216144049 dot GA19212 at spoyarek dot pnq dot redhat dot com>
On 12/16/2013 09:40 AM, Siddhesh Poyarekar wrote:
> On Mon, Dec 16, 2013 at 09:32:12AM -0500, Carlos O'Donell wrote:
>> Maybe, maybe not, but that would be a distinct patch *after*
>> this initial checkin to make the function distinct.
>>
>> I don't want to wrap the elements in a struct because that
>> breaks the optimizations used during inlining.
>
> Yeah, making a struct out of it is pointless. We could clean up the
> arguments later.
It's not entirely pointless. A pointer to a structure makes the call
optimal when the ABI requires pass by stack, you need only push a
single register, and pop a single register before doing register+offset
loads.
One question I had was: Why is the original function __attribute_noinline__?
I didn't mention this but I removed that marker from the code because
I find it ridiculous that we impose these constraints on the developer
compiling the code. If they want to compile with -O3 the compiler should
inline it, and if they want to compile with -Os the compiler should not
inline it (or do whatever the option implies for that compiler).
Does that make sense?
Cheers,
Carlos.