Changes between Version 6 and Version 7 of MemcpyOptimizations


Ignore:
Timestamp:
Mar 9, 2014 6:44:51 AM (17 months ago)
Author:
tibbe
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MemcpyOptimizations

    v6 v7  
    77The 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 optimization hint by the backends.
    88
    9 The 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.
     9The 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 than a generic case higher up. Currently only the X86 backend unrolls these primitives though, SPARC and !PowerPC both just call the corresponding C functions.
    1010
    1111== Unrolling heuristics ==