Re: Old compiler optimizations in installed headers

[Joseph Myers <joseph at codesourcery dot com>]

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