llvm.memcpy intrinsics.

clang generates llvm.memcpy.* intrinsics for our port.
Now we are linking a .bc version of the standard library. Do we have to
include a version of these intrinsics in the .bc librrary? If yes, do we
have some already written version?

Or do we have to leave them for llc to convert them in to memcpy and
then provide an binary version of lib with these functions ?

- Sanjiv

clang generates llvm.memcpy.* intrinsics for our port.
Now we are linking a .bc version of the standard library. Do we have to
include a version of these intrinsics in the .bc librrary?

You can't implement an intrinsic, at least not directly.

If yes, do we
have some already written version?

The difficultly of writing an implementation of memcpy corresponds
closely to how much you care about its performance... the simplest
implementation is something like "while (len--) *dest++ = *src++;".

Or do we have to leave them for llc to convert them in to memcpy and
then provide an binary version of lib with these functions ?

That's probably the easiest way to deal with it; I think llc can
sometimes generate memcpy/memmove/memset even when the corresponding
intrinsics are never called. Alternatively, if you're using a custom
target, you can custom-lower it however you want by overriding
EmitTargetCodeForMemcpy; see
X86TargetLowering::EmitTargetCodeForMemcpy for an example.

-Eli

You can leave a memcpy implementation in your .bc file so long as it
has the appropriate attributes so it doesn't get removed by dead code
elimination, you are fine. This problem also comes up in systems
without the standard library like OS kernels. Also, they need to have
the expected linkage (just saying...).

Andrew