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 jos...@codesourcery.com
