Re: _HAVE_STRING_ARCH_strcpy/strncpy and ppc64 macro expansion of strcpy/strncpy.

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

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.