Lowering intrinsics in Codegen.

For lowering llvm.memcpy.* etc SelectionDAG::getMemcpy generates a libcall to "memcpy" as a last resort. See the code snippets below.

// FIXME: pass in DebugLoc
  std::pair<SDValue,SDValue> CallResult =
    TLI.LowerCallTo(Chain, Type::VoidTy,
                    false, false, false, false, 0, CallingConv::C, false,
                    getExternalSymbol("memcpy", TLI.getPointerTy()),
                    Args, *this, dl);
  return CallResult.second;

I have two questions here:

1. Is it okay to allow the targets to choose the name, similar to RTLIB:: enum way for other calls. ?

2. Why a prototype for "memcpy" isn't being added?

Could we have done this intrinsic lowering using the IntrinsicLowering class?

- Sanjiv

For lowering llvm.memcpy.* etc SelectionDAG::getMemcpy generates a
libcall to "memcpy" as a last resort. See the code snippets below.

Right.

I have two questions here:

1. Is it okay to allow the targets to choose the name, similar to
RTLIB:: enum way for other calls. ?

Sure.

2. Why a prototype for "memcpy" isn't being added?

To the module? Ideally, code generation should not modify the module at all. We're not to that point yet, but we don't want to make gratuitous changes. Your backend should not key off declarations in the module, it should look from references in the code. This is what (e.g.) the ppc/x86/arm backends due for external function stubs etc: all references (including "external symbol" references) from the code get added to maps and they are processed at the end of the translation unit.

Could we have done this intrinsic lowering using the IntrinsicLowering
class?

The SelectionDag code generator doesn't use intrinsic lowering.

-Chris