Re: Builtin expansion versus headers optimization: Reductions

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 4 Jun 2015, Ondřej Bílka wrote:

> As I commented on libc-alpha list that for string functions a header
> expansion is better than builtins from maintainance perspective and also
> that a header is lot easier to write and review than doing that in gcc
> Jeff said that it belongs to gcc. When I asked about benefits he
> couldn't say any so I ask again where are benefits of that?

One might equally ask where the benefits are of doing it in glibc headers 
and so not having optimizations in kernel space, not having optimizations 
on existing systems where using a newer GCC is much easier and more common 
than using a newer glibc, not having information from optimizers about 
alignment, etc.

The aim should be to make the GNU system as a whole as good as possible 
rather than to argue for the merits of implementing things in the piece of 
the system you're most familiar with.  That means working collaboratively 
to understand the best place for each optimization to go and get it 
implemented.

Are you offering to collaborate with any interested GCC developers on 
understanding the circumstances in which each transformation is correct 
and beneficial and getting it implemented in the most appropriate place 
(which may sometimes involve work in both places - for example, adding 
implementation-namespace entry points for functions in glibc, or adding 
pragmas to glibc headers to inform GCC about available entry points or 
their performance characteristics)?

> Here I cover problem of reductions that you should use foo instead bar.
> Problem is that these depend on quality of implementation so its
> questionable how to check these in gcc.

I don't think either GCC or glibc should generally be working around 
suboptimality of the other.  So glibc should generally expect GCC 
optimizations to be effective, and GCC should generally expect libc 
functions to be optimally implemented (so calling a more specific function 
is generally better than calling a less specific one - and only if any 
overhead would be constant, as in the memcpy / mempcpy case, are icache 
issues from calling less common functions relevant).

> We have similar problem with strcpy/stpcpy and that they increase cache
> pressure with identical code. To unify these you need to go 
> in strcpy => stpcpy direction as getting length again is expensive.

Watch out for namespace issues here.  
<https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00409.html> is my analysis 
of the circumstances in which it's OK to generate calls to functions not 
called by the user's program.

> Then there is missed optimization by gcc for following reduction chain
> 
> strchr (x, 0) -> strchrnul (x, 0) -> rawmemchr (x, 0) -> x + strlen (x)

strchr -> strlen optimization is meaningful even when the nonstandard 
functions strchrnul and rawmemchr are not available.

> Next missed reduction is
> 
> strdup (x) => s = strlen (x); memcpy (malloc (s+1), x, s+1)

That's not valid when malloc returns NULL; you need to insert a check for 
NULL there.

> Again is this worth a gcc pass?

This isn't a matter of compiler passes; it's additional checks in existing 
built-in function handling.  Maybe that built-in function handling should 
move to the match-and-simplify infrastructure (some, for libm functions 
and bswap, already has) to make this even simpler to implement.

-- 
Joseph S. Myers
joseph@codesourcery.com