This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Old compiler optimizations in installed headers
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 29 May 2015 11:03:42 +0000
- Subject: Re: Old compiler optimizations in installed headers
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1505221433160 dot 16611 at digraph dot polyomino dot org dot uk> <20150524225100 dot GA22541 at domone> <alpine dot DEB dot 2 dot 10 dot 1505281612020 dot 16930 at digraph dot polyomino dot org dot uk> <20150529063951 dot GB7535 at domone>
On Fri, 29 May 2015, OndÅej BÃlka wrote:
> On several simple optimizations both are correct so question is which is
> easier to implement. Current gcc shown evidence that compiler
> optimization isn't one. You could have performance regression with
> almost all functions due to underlying bugs in memcmp and memcpy
> generation.
In most cases you haven't given enough information (such as test cases,
compiler options and confirmation this is using current GCC 6) to convince
me that there are actually problems (an awful lot of people complaining
about compiler performance are using inappropriate options or compiler
configurations).
> As these are outstanding bugs lets be practical here. Joseph how long do
> you think it will take to fix them. As these are present for five years
> I wouldn't be surprised to wait another five years.
>
> So I would make deadline of three months, if gcc cannot produce a patch
> within that going compiler optimization way does take too long.
I don't think you can meaningfully count time without starting with a
constructive proposal in the right place. That means bugs in GCC Bugzilla
for each issue, constructively engaging with the points of view other
people present in response to those bugs, a meta-bug depending on all such
bugs, and starting a discussion on the GCC mailing list pointing to that
bug and offering your advice and expertise on e.g. how common different
sorts of string function inputs are in different workloads. The message
in such discussions should be one of seeking collaborators to improve
string function optimization in the GNU system as a whole, not "X sucks"
or "only this particular form of benchmarking is valid" or "changing Y is
easier than changing Z".
> Also you have other problem with gcc/header issue. I was asked if its
> possible to use functions with partially expanded header, so you would
> call new symbol like memcmp_aligned to save cost of checking header
> again. I don't think that adding a expansion in gcc is sane.
It seems perfectly reasonable for glibc to define *reserved-namespace*
ABIs for such cases that GCC can then generate calls to (noting that GCC
often has compile-time knowledge of alignment). Indeed, the ARM EABI
defines functions such as __aeabi_memcpy4 and __aeabi_memclr8 for aligned
inputs - right now, those functions in glibc are wrappers for the generic
ones, so slower than the generic ones, and GCC doesn't generate calls to
them. Changing just one without the other wouldn't be that useful - but
as a collaboration, making the functions faster in glibc *and* making GCC
generate calls using the alignment information it has, given new enough
glibc on the target, would make sense.
Again, the principle is to work out collaboratively what's best for the
GNU system as a whole (respecting that different people use the system in
different ways and what's useful for one person may be problematic for
others, so there is a need to compromise with other requirements than just
the greatest optimization of particular programs), and to work as needed
with experts on each part of the system to achieve those goals. Not to
focus only on the part of the system you're most familiar with.
--
Joseph S. Myers
joseph@codesourcery.com