questions on builtin memcpy, memset

[Paul Koning <pkoning at equallogic dot com>]

I was looking at some code that is doing a lot of memset, bzero,
memcpy, etc., and wondering why it doesn't optimize as well as
expected.

Two observations.

For a MIPS target, when memcpy is expanded as straight code, if one of
the two operands has less alignment than the other then the lesser is
used.  This in spite of the fact that the generated code ends up doing
loads into registers, then stores.  So, for example, a memcpy from
char to int on a MIPS-1 target generates lwl/lwr pairs and swl/swr
pairs, even though a simple sw would suffice.

The cause of this, as far as I can tell, is that the block move RTL
pattern generated for this has only a single "alignment" argument,
rather than separate source and dest alignments.  This prevents the
back end from generating the best possible code.

Second -- I see memcpy operations optimized for fairly long moves, but
similar length memset or bzero operations are not optimized.  On the
MIPS at least, it appears that I get a libcall for any memset or bzero
that requires more than one store instruction... which doesn't seem
right. 

In trying to work around that, I noticed code in builtins.c to detect
memcpy from string constants, which is supposed to generate stores of
the data directly rather than loading from the string constant.  But I
don't see that happening, at least not in the 3.0.x and
3.1(experimental) version compilers I have lying around.  The code in
question seems to be old enough to be in those compilers, so I wonder
what is missing.

Test case for that last item:

//#include <stdlib.h>

#define ZEROES "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"

#define bzero(dest,len) memcpy (dest, ZEROES, len)

void *bar;
int *ip, *jp;
char *cp;

void f3(void)
{
    bzero (ip, 8);
    bzero (jp, 4);
    bzero (cp, 4);
}


	paul