The CBE is emitting: unsigned char *memcpy(unsigned char *, unsigned char *, unsigned int ); unsigned char *memcpy(unsigned char *, unsigned char *, unsigned long long ); which causes the C compiler to barf. This prevents burg from working with the CBE and also prevents bugpoint from working, which doesn't allow us to track down why jit/llc also fail. -Chris
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.