1. 24 Feb, 2012 2 commits
  2. 23 Feb, 2012 3 commits
  3. 17 Feb, 2012 2 commits
  4. 14 Feb, 2012 1 commit
  5. 10 Jan, 2012 1 commit
    • dterei's avatar
      Track STG live register information for use in LLVM · 4384e146
      dterei authored
      We now carry around with CmmJump statements a list of
      the STG registers that are live at that jump site.
      This is used by the LLVM backend so it can avoid
      unnesecarily passing around dead registers, improving
      perfromance. This gives us the framework to finally
      fix trac #4308.
  6. 06 Jan, 2012 2 commits
  7. 05 Jan, 2012 2 commits
  8. 19 Dec, 2011 1 commit
  9. 29 Nov, 2011 1 commit
  10. 22 Nov, 2011 1 commit
  11. 17 Nov, 2011 2 commits
  12. 01 Nov, 2011 2 commits
    • dmp's avatar
      Ignore stdcall c-call in native codegen on x86_64 · 521157f9
      dmp authored
      The stdcall calling convention is not supported on x86_64.
      When an ffi import requests stdcall, a warning is issued as
      desired by #3336. However, the native codegen was still
      generating code that expected the callee to cleanup the
      stack arguments when calling a c function that requests
      This patch changes the codegen to actually use the ccall
      calling convention as intended.
      Signed-off-by: dterei's avatarDavid Terei <davidterei@gmail.com>
    • 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>
  13. 23 Oct, 2011 2 commits
  14. 14 Oct, 2011 1 commit
  15. 02 Oct, 2011 1 commit
  16. 30 Aug, 2011 2 commits
  17. 25 Aug, 2011 2 commits
  18. 16 Aug, 2011 1 commit
  19. 09 Aug, 2011 1 commit
  20. 21 Jul, 2011 1 commit
  21. 20 Jul, 2011 1 commit
  22. 19 Jul, 2011 1 commit
  23. 15 Jul, 2011 2 commits
    • Ian Lynagh's avatar
      Small refactoring · 83e8244f
      Ian Lynagh authored
    • 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.
  24. 05 Jul, 2011 1 commit
    • 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.
  25. 27 Jun, 2011 1 commit
  26. 17 Jun, 2011 3 commits