This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 01/10] Add vectorized getenv for glibc use
- From: Andi Kleen <andi at firstfloor dot org>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot intel dot com>
- Date: Fri, 17 May 2013 17:48:54 +0200
- Subject: Re: [PATCH 01/10] Add vectorized getenv for glibc use
- References: <1368756775-23245-1-git-send-email-andi at firstfloor dot org> <1368756775-23245-2-git-send-email-andi at firstfloor dot org> <20130517073751 dot GA24334 at domone dot kolej dot mff dot cuni dot cz>
On Fri, May 17, 2013 at 09:37:51AM +0200, OndÅej BÃlka wrote:
> On Thu, May 16, 2013 at 07:12:46PM -0700, Andi Kleen wrote:
> > From: Andi Kleen <ak@linux.intel.com>
> >
> > This adds a general "vectorized getenv" for glibc internal use.
> > The motivation is to allow subsystems to access environment variables
> > cheaply without having to rescan the environment completely.
> >
>
> > + if (__builtin_expect ((*current)[0] == 'G', 0)
> > + && (*current)[1] == 'L' && (*current)[2] == 'I'
> > + && (*current)[3] == 'B' && (*current)[4] == 'C'
> > + && (*current)[5] == '_')
> This pattern repeats few times. A memcmp(current,"GLIBC",5) is shorter.
Just copied this from the dynamic linker.
Don't really care about "short" just that the first character
comparison is fast. In principle this could be all vectorized
too at least on x86 to compare 32 or 64bits, but I was slightly
worried about overrunning the end.
If you want to fix it I think it should be a indepdendent followup all over
the tree. Most likely it would be a candidate for coccinelle script.
So I'll just leave it as is for now.
-Andi