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
On Jul 29, 2009, at 4:56 AM, Sanjiv Gupta wrote:> 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
Apparently Analagous Threads
- [LLVMdev] [RFC] Splitting init.trampoline into init.trampoline and adjust.trampoline
- Why did "llvm.memcpy" changed when emitting an object file?
- [LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
- [LLVMdev] About implementing new intrinsic
- [LLVMdev] replace hardcoded function names by intrinsics