This patch fixes the problem:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070122/043420.html

I'm not completely happy with it, however. It just forces memcpy and memmove to
be 32-bit. This might not work so well with large "count" values on a 64-bit
machine as the high 32-bits are being truncated. However, since the only clients
are CBE and LLI interpreter, and both target 32-bit machines, this shouldn't
cause any significant problems.

The real question is .. why does llvm generate both llvm.memcpy.i32 and
llvm.memcpy.i64 in the same program?

The patch completely breaks 64-bit targets, please revert it. It should use targetdata to figure out the
size of a pointer, and use that as the size_t value.

-Chris

So, how do you unbreak llvm.memcpy.64 on a 32-bit platform? Truncating the value
down to 32-bits is also wrong.

No it isn't. Clearly the value has to be dynamically 32-bits or smaller if your pointer is only 32-bits.

A proper fix for this was made with these patches:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070129/043434.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070129/043435.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070129/043436.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070129/043437.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070129/043438.html

This endows IntrinsicLowering with TargetData and uses the IntPtrTy to get the
right prototype for memcpy/memmove/memset given the intended target. It also
adjusts CBE and LLI to pass the TargetData to IntrinsicLowering.