Changes between Version 4 and Version 5 of MemcpyOptimizations


Ignore:
Timestamp:
Mar 9, 2014 6:42:54 AM (18 months ago)
Author:
tibbe
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MemcpyOptimizations

    v4 v5  
    55== Implementation ==
    66
    7 The primitives are implemented as three [wiki:Commentary/Compiler/CmmType Cmm language] [wiki:Commentary/Compiler/CmmType#OperatorsandPrimitiveOperations CallishMachOp`s], defined in [[GhcFile(compiler/cmm/CmmMachOp.hs)]]. The code generator generates calls to these `CallishMachOp`s using three utility functions: `emitMemcpyCall`, `emitMemmoveCall`, and `emitMemsetCall`, defined in [[GhcFile(compiler/codeGen/CgPrimOp.hs)]] (old code generator) and [[GhcFile(compiler/codeGen/StgCmmPrim.hs)]] (new code generator). The helper functions take an extra parameter that indicates the alignment of the arguments, which is used as a optimisation hint by the backends.
     7The primitives are implemented as three [wiki:Commentary/Compiler/CmmType Cmm language] [wiki:Commentary/Compiler/CmmType#OperatorsandPrimitiveOperations CallishMachOp`s], defined in [[GhcFile(compiler/cmm/CmmMachOp.hs)]]. The code generator generates calls to these `CallishMachOp`s using three utility functions: `emitMemcpyCall`, `emitMemmoveCall`, and `emitMemsetCall`, defined in [[GhcFile(compiler/codeGen/StgCmmPrim.hs)]]. The helper functions take an extra parameter that indicates the alignment of the arguments, which is used as a optimisation hint by the backends.
    88
    99The reason the primitives are unrolled in the backends, instead of in the code generator, is to allow us to make use of LLVM's `memcpy`/`memmove`/`memset` intrinsics, which LLVM  optimizes well. In the x86/x86-64 backend we unroll the primitives ourselves. The different native code generator backends can also generate more efficient code then a generic case higher up. Currently only the X86 backend unrolls these primitives though, SPARC and !PowerPC both just call the corresponding C functions.