This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: _HAVE_STRING_ARCH_strcpy/strncpy and ppc64 macro expansion of strcpy/strncpy.
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Wed, 26 Oct 2016 16:09:25 -0200
- Subject: Re: _HAVE_STRING_ARCH_strcpy/strncpy and ppc64 macro expansion of strcpy/strncpy.
- Authentication-results: sourceware.org; auth=none
- References: <1477494262.5924.13.camel@linux.vnet.ibm.com>
On 26/10/2016 13:04, Aaron Sawdey wrote:
> At present, powerpc uses the generic macros for strcpy/strncpy
> expansion, which includes an expansion into code that compares the
> strings character by character if one string is a string constant and
> is less than 4 chars.
>
> I'm currently working on builtin expansion of strcmp/strncmp in gcc7
> for powerpc, similar to the memcmp builtin expansion I checked in a
> couple weeks ago. This will potentialy generate much better code for
> these short comparisons because gcc often knows the alignment which
> allows it to generate word or doubleword comparisons reducing the
> number of branches greatly.
>
> However as things currently stand, comparisons to constant strings < 4
> chars never see a strcmp/strncmp call because they get macro expanded
> into comparison code. What would be helpful would be a change to have
> powerpc specific code that doesn't invoke __strcmp_cg if compiled with
> gcc7 or higher.
>
> Thanks,
> Aaron
>
I think back when we lacked gcc support for string routing optimization
the string{2,3}.h header optimization made sense, but currently it add
more issue with multiple arch definition permutation and differences.
For your specific issue I think it would be feasible to create a
installed string.h with a arch-specific optimization (as for x86
and s390) with something like:
#define _HAVE_STRING_ARCH_strcmp
#ifndef _FORCE_INLINES
__STRING_INLINE int
strcmp (const char *__s1, const char *__s2)
{
return __builtin_strcmp (__s1, __s2);
}
#endif
But I would rather prefer to evaluate if we *really* require the
default and convoluted strcmp macro optimization. I think it would
be just better to just remove it and let it the compiler handle it.