This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove unnecessary locking when reading iconv configuration [BZ #22062]
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Arjun Shankar <arjun dot is at lostca dot se>, libc-alpha at sourceware dot org
- Date: Fri, 3 Nov 2017 10:59:30 -0700
- Subject: Re: [PATCH] Remove unnecessary locking when reading iconv configuration [BZ #22062]
- Authentication-results: sourceware.org; auth=none
- References: <20171026111843.GB79519@aloka.lostca.se> <0afeb00d-f251-379b-e0eb-058d8f052d7a@redhat.com> <7c91564a-bc53-7875-9a8a-833f5faff432@redhat.com> <b0347b17-8344-1bbf-ec0e-620a758c3963@redhat.com>
On 11/03/2017 07:45 AM, Florian Weimer wrote:
> On 11/01/2017 05:36 AM, Carlos O'Donell wrote:
>> On 10/30/2017 09:24 AM, Florian Weimer wrote:
>>>> - struct path_elem *result;
>>>
>>> I think it makes sense to keep the result variable because it can
>>> be kept in a register across calls. In contrast, the global
>>> variable has to be reloaded.
>>
>> What's the difference between loading the value of the global into
>> result (a register or stack local) and then using it, versus using
>> the value of the global directly, which gcc will optimize by
>> loading it into a register or a pseudo (which may be given a stack
>> slot)?
>
> I doubt GCC will perform the optimization because you call quite a
> few functions for which GCC does not know if they will modify the
> global or not.
Good point. Either way I think it makes the code more readable and
the diff smaller if the original local is kept, so I suggested the
same thing for different reasons in my review.
--
Cheers,
Carlos.