llvm dev - Jul 2009 - [LLVMdev] 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

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