Re: Old compiler optimizations in installed headers

[OndÅej BÃlka <neleai at seznam dot cz>]

On Fri, May 22, 2015 at 03:03:01PM +0000, Joseph Myers wrote:
> We've recently had a discussion of whether it makes sense to keep various 
> macros and inline functions in bits/string2.h that are only used for old 
> GCC versions and only serve to optimize cases of small / constant 
> arguments with those versions.  A similar issue applies to such things as 
> inline __signbit* definitions in bits/mathinline.h - given 
> <https://sourceware.org/ml/libc-alpha/2015-05/msg00521.html> could we just 
> remove the various inlines on the basis that optimization for compilers 
> before GCC 4.0 isn't a concern - and probably to various other inlines.
> 
> There was previously a discussion with a proposal in 
> <https://sourceware.org/ml/libc-alpha/2013-01/msg00157.html> and with 
> <https://sourceware.org/ml/libc-alpha/2013-01/msg00270.html> saying to 
> avoid optimization regressions for old compilers.
> 
> Regarding what's supported at all, the baseline is C90 or C++98 plus long 
> long support (although there are various places where headers in fact 
> depend on other extensions to provide particular functionality).
> 
> Meanwhile, lots of architecture-specific .S function implementations in 
> NPTL (especially, but maybe also elsewhere) have been removed, with 
> benchmark evidence showing they don't actually provide better performance 
> but do cause significant trouble in maintenance.
> 
> I'd like to propose that:
> 
> (a) if an optimization could clearly be done in the compiler - if it only 
> depends on the standard semantics of standard functions, or fully-defined 
> semantics of glibc functions that it would be reasonable to encode into 
> GCC, rather than e.g. generating calls to a glibc-internal function - then 
> we should be wary of adding it to glibc's headers in the first place: in 
> accordance with principles of GNU projects working together, it's better 
> to add the optimization to GCC; and
>
I disagree for simple reason of cost. Its considerably easier to write a
inline function that does transformation than to write equivalent gcc
pass.

Result is that a lot of builtin cause performance regressions. I would
need to review them separately as they don't inspire lot of confidence.

I just found that gcc also seriously messes up strcmp with constant
strings. It uses rep cmpsb which is around three times slower than
libcall in following simple test, complile a.c and b.c separately then
link with main.c.

a.c:

#include <string.h>
int strcmp2(char *c)
{
  return strcmp(c, "ahtusntueoahsntsnthusnthueoasnth");

}


b.c:

#include <string.h>
extern char *str;
int strcmp2(char *c)
{
  return strcmp(c, str);

}

main.c:

char *str  = "ahtusntueoahsntsnthusnthueoasnth";
char *str2 = "bhtusntueoahsntsnthusnthueoasnti";

int main()
{
  int i;
  for (i=0;i<10000000;i++)
    strcmp2 (str2);
}