Re: Totally bogus string optimizations

[Ulrich Drepper <drepper at redhat dot com>]

Bernd Schmidt <bernds@redhat.co.uk> writes:

> #include <string.h>
> char *p;
> int main ()
> {
>   strcpy (p, "Foobar");
> }
> 
> causes _horrendous_ assembly code to be generated.  Apparently, for a machine
> that does not define _STRING_ARCH_unaligned, /usr/include/bits/string2.h
> contains totally bogus code.

Well, maybe you should look then at the compiler.  We just describe
something in C which the compiler isn't able to optimize.  It's the
same old story: people are asked to use inline functions but when they
do they are screwed because the compiler is handling them in a
horrible way.

They used to work just fine and is much faster back then.  But in the
meantime gcc apparently was broken.

For this case (with _STRING_ARCH_unaligned), why isn't gcc recognizing
an inline function called with all constant parameters and so does not
even try to create the parameter list?  We've spent quite some time in
the past to ensure that accessing individual bytes in string constants
is performed at compile time.  If all this is broken now the results
must be horrible.

And no, the compiler is not able to optimize as good.  If the compiler
would work correctly an strcpy() like your example would be
transformed into something like this


    ...get dest address in %eax...
   movl $0x626f6f46, (%eax)
   movw $0x7261, 4(%eax)
   movb $0, 6(%eax)


which is much better since we have no loading, no relocation (this is
a data relocation which always has to be performed), and not another
string constant.


So, try to find out why gcc screws up so much.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------