1. 10 Jan, 2012 2 commits
  2. 06 Jan, 2012 2 commits
  3. 06 Dec, 2011 1 commit
    • dterei's avatar
      Fix trac # 5486 · fe60dd4a
      dterei authored
      LLVM has a problem when the user imports some FFI types
      like memcpy and memset in a manner that conflicts with
      the types that GHC uses internally.
      So now we pre-initialise the environment with the most
      general types for these functions.
  4. 04 Dec, 2011 4 commits
  5. 29 Nov, 2011 1 commit
  6. 28 Nov, 2011 1 commit
    • Ian Lynagh's avatar
      Implement a capi calling convention; fixes #2979 · 36f8cabe
      Ian Lynagh authored
      In GHC, this provides an easy way to call a C function via a C wrapper.
      This is important when the function is really defined by CPP.
      Requires the new CApiFFI extension.
      Not documented yet, as it's still an experimental feature at this stage.
  7. 22 Nov, 2011 4 commits
  8. 17 Nov, 2011 1 commit
    • dterei's avatar
      Fix #4211: No need to fixup stack using mangler on OSX · 8a1c644a
      dterei authored
      We now manage the stack correctly on both x86 and i386, keeping
      the stack align at (16n bytes - word size) on function entry
      and at (16n bytes) on function calls. This gives us compatability
      with LLVM and GCC.
  9. 01 Nov, 2011 1 commit
    • dmp's avatar
      Change stack alignment to 16+8 bytes in STG code · a9ce3611
      dmp authored
      This patch changes the STG code so that %rsp to be aligned
      to a 16-byte boundary + 8. This is the alignment required by
      the x86_64 ABI on entry to a function. Previously we kept
      %rsp aligned to a 16-byte boundary, but this was causing
      problems for the LLVM backend (see #4211
      We now don't need to invoke llvm stack mangler on
      x86_64 targets. Since the stack is now 16+8 byte algined in
      STG land on x86_64, we don't need to mangle the stack
      manipulations with the llvm mangler.
      This patch only modifies the alignement for x86_64 backends.
      Signed-off-by: dterei's avatarDavid Terei <davidterei@gmail.com>
  10. 15 Oct, 2011 1 commit
  11. 02 Oct, 2011 1 commit
  12. 25 Aug, 2011 2 commits
  13. 21 Aug, 2011 2 commits
    • kgardas's avatar
      enable ARM specific target data layout and triple again · 748883b4
      kgardas authored
      This patch is allowed by the 'on ARMv7 with VFPv3[D16] support pass
       appropriate -mattr value to LLVM llc' patch. The trick is that LLVM
      by default (probably!) does not enable VFP, but GHC requires it
      so LLVM's llc asserts on unavailable floating point register. i.e. GHC/LLVM
      backend compiles into LLVM code which is using floats, but llc thinks
      no float regs for this are available. Passing appropriate llc option
      which is implemented in patch mentioned above fixes this issue.
    • dterei's avatar
      Add popcnt support to LLVM backend · 2906db6c
      dterei authored
  14. 10 Aug, 2011 5 commits
  15. 18 Jul, 2011 1 commit
  16. 15 Jul, 2011 1 commit
    • Ian Lynagh's avatar
      More work towards cross-compilation · f07af788
      Ian Lynagh authored
      There's now a variant of the Outputable class that knows what
      platform we're targetting:
      class PlatformOutputable a where
          pprPlatform :: Platform -> a -> SDoc
          pprPlatformPrec :: Platform -> Rational -> a -> SDoc
      and various instances have had to be converted to use that class,
      and we pass Platform around accordingly.
  17. 06 Jul, 2011 3 commits
  18. 05 Jul, 2011 2 commits
    • batterseapower's avatar
    • batterseapower's avatar
      Refactoring: use a structured CmmStatics type rather than [CmmStatic] · 54843b5b
      batterseapower authored
      I observed that the [CmmStatics] within CmmData uses the list in a very stylised way.
      The first item in the list is almost invariably a CmmDataLabel. Many parts of the
      compiler pattern match on this list and fail if this is not true.
      This patch makes the invariant explicit by introducing a structured type CmmStatics
      that holds the label and the list of remaining [CmmStatic].
      There is one wrinkle: the x86 backend sometimes wants to output an alignment directive just
      before the label. However, this can be easily fixed up by parameterising the native codegen
      over the type of CmmStatics (though the GenCmmTop parameterisation) and using a pair
      (Alignment, CmmStatics) there instead.
      As a result, I think we will be able to remove CmmAlign and CmmDataLabel from the CmmStatic
      data type, thus nuking a lot of code and failing pattern matches. This change will come as part
      of my next patch.
  19. 28 Jun, 2011 1 commit
  20. 25 Jun, 2011 2 commits
  21. 13 Jun, 2011 1 commit
  22. 31 May, 2011 1 commit