This is the mail archive of the
mailing list for the GCC project.
Re: Builtin expansion versus headers optimization: Reductions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: <gcc at gcc dot gnu dot org>, <law at redhat dot org>, <libc-alpha at sourceware dot org>
- Date: Thu, 4 Jun 2015 12:26:03 +0000
- Subject: Re: Builtin expansion versus headers optimization: Reductions
- Authentication-results: sourceware.org; auth=none
- References: <20150604105929 dot GA19141 at domone>
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
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
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
> 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