1. 06 Dec, 2016 1 commit
  2. 12 Nov, 2015 1 commit
    • olsner's avatar
      Implement function-sections for Haskell code, #8405 · 4a32bf92
      olsner authored
      This adds a flag -split-sections that does similar things to
      -split-objs, but using sections in single object files instead of
      relying on the Satanic Splitter and other abominations. This is very
      similar to the GCC flags -ffunction-sections and -fdata-sections.
      
      The --gc-sections linker flag, which allows unused sections to actually
      be removed, is added to all link commands (if the linker supports it) so
      that space savings from having base compiled with sections can be
      realized.
      
      Supported both in LLVM and the native code-gen, in theory for all
      architectures, but really tested on x86 only.
      
      In the GHC build, a new SplitSections variable enables -split-sections
      for relevant parts of the build.
      
      Test Plan: validate with both settings of SplitSections
      
      Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari
      
      Reviewed By: simonmar, thomie, bgamari
      
      Subscribers: hsyl20, erikd, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1242
      
      GHC Trac Issues: #8405
      4a32bf92
  3. 14 Apr, 2015 1 commit
  4. 10 Feb, 2015 1 commit
    • Ben Gamari's avatar
      llvmGen: move to LLVM 3.6 exclusively · 5d5abdca
      Ben Gamari authored
      Summary:
      Rework llvmGen to use LLVM 3.6 exclusively. The plans for the 7.12 release are to ship LLVM alongside GHC in the interests of user (and developer) sanity.
      
      Along the way, refactor TNTC support to take advantage of the new `prefix` data support in LLVM 3.6. This allows us to drop the section-reordering component of the LLVM mangler.
      
      Test Plan: Validate, look at emitted code
      
      Reviewers: dterei, austin, scpmw
      
      Reviewed By: austin
      
      Subscribers: erikd, awson, spacekitteh, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D530
      
      GHC Trac Issues: #10074
      5d5abdca
  5. 21 Nov, 2014 1 commit
    • Ben Gamari's avatar
      llvmGen: Compatibility with LLVM 3.5 (re #9142) · e16a342d
      Ben Gamari authored
      Due to changes in LLVM 3.5 aliases now may only refer to definitions.
      Previously to handle symbols defined outside of the current commpilation
      unit GHC would emit both an `external` declaration, as well as an alias
      pointing to it, e.g.,
      
          @stg_BCO_info = external global i8
          @stg_BCO_info$alias = alias private i8* @stg_BCO_info
      
      Where references to `stg_BCO_info` will use the alias
      `stg_BCO_info$alias`. This is not permitted under the new alias
      behavior, resulting in errors resembling,
      
          Alias must point to a definition
          i8* @"stg_BCO_info$alias"
      
      To fix this, we invert the naming relationship between aliases and
      definitions. That is, now the symbol definition takes the name
      `@stg_BCO_info$def` and references use the actual name, `@stg_BCO_info`.
      This means the external symbols can be handled by simply emitting an
      `external` declaration,
      
          @stg_BCO_info = external global i8
      
      Whereas in the case of a forward declaration we emit,
      
          @stg_BCO_info = alias private i8* @stg_BCO_info$def
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D155
      e16a342d
  6. 20 Oct, 2014 1 commit
  7. 02 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Place static closures in their own section. · b23ba2a7
      Edward Z. Yang authored
      Summary:
      The primary reason for doing this is assisting debuggability:
      if static closures are all in the same section, they are
      guaranteed to be adjacent to one another.  This will help
      later when we add some code that takes section start/end and
      uses this to sanity-check the sections.
      
      Part of remove HEAP_ALLOCED patch set (#8199)
      Signed-off-by: Edward Z. Yang's avatarEdward Z. Yang <ezyang@mit.edu>
      
      Test Plan: validate
      
      Reviewers: simonmar, austin
      
      Subscribers: simonmar, ezyang, carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D263
      
      GHC Trac Issues: #8199
      b23ba2a7
  8. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  9. 27 Jun, 2013 2 commits
    • Peter Wortmann's avatar
      Major Llvm refactoring · a948fe83
      Peter Wortmann authored
      This combined patch reworks the LLVM backend in a number of ways:
      
      1. Most prominently, we introduce a LlvmM monad carrying the contents of
         the old LlvmEnv around. This patch completely removes LlvmEnv and
         refactors towards standard library monad combinators wherever possible.
      
      2. Support for streaming - we can now generate chunks of Llvm for Cmm as
         it comes in. This might improve our speed.
      
      3. To allow streaming, we need a more flexible way to handle forward
         references. The solution (getGlobalPtr) unifies LlvmCodeGen.Data
         and getHsFunc as well.
      
      4. Skip alloca-allocation for registers that are actually never written.
         LLVM will automatically eliminate these, but output is smaller and
         friendlier to human eyes this way.
      
      5. We use LlvmM to collect references for llvm.used. This allows places
         other than cmmProcLlvmGens to generate entries.
      a948fe83
    • Peter Wortmann's avatar
      Extend globals to aliases · 720a87c7
      Peter Wortmann authored
      Also give them a proper constructor - getGlobalVar and getGlobalValue
      map directly to the accessors.
      720a87c7
  10. 01 Feb, 2013 1 commit
  11. 12 Nov, 2012 1 commit
    • Simon Marlow's avatar
      Remove OldCmm, convert backends to consume new Cmm · d92bd17f
      Simon Marlow authored
      This removes the OldCmm data type and the CmmCvt pass that converts
      new Cmm to OldCmm.  The backends (NCGs, LLVM and C) have all been
      converted to consume new Cmm.
      
      The main difference between the two data types is that conditional
      branches in new Cmm have both true/false successors, whereas in OldCmm
      the false case was a fallthrough.  To generate slightly better code we
      occasionally need to invert a conditional to ensure that the
      branch-not-taken becomes a fallthrough; this was previously done in
      CmmCvt, and it is now done in CmmContFlowOpt.
      
      We could go further and use the Hoopl Block representation for native
      code, which would mean that we could use Hoopl's postorderDfs and
      analyses for native code, but for now I've left it as is, using the
      old ListGraph representation for native code.
      d92bd17f
  12. 16 Sep, 2012 1 commit
  13. 12 Sep, 2012 1 commit
    • ian@well-typed.com's avatar
      Pass DynFlags down to bWord · f611396a
      ian@well-typed.com authored
      I've switched to passing DynFlags rather than Platform, as (a) it's
      simpler to not have to extract targetPlatform in so many places, and
      (b) it may be useful to have DynFlags around in future.
      f611396a
  14. 04 Dec, 2011 1 commit
    • dterei's avatar
      Fix ugly complexity issue in LLVM backend (#5652) · 7626b2b9
      dterei authored
      Compile time still isn't as good as I'd like but no easy changes
      available. LLVM backend could do with a big rewrite to improve
      performance as there are some ugly designs in it.
      
      At least the test case isn't 10min anymore, just a few seconds now.
      7626b2b9
  15. 02 Oct, 2011 1 commit
  16. 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.
      54843b5b
  17. 24 Jan, 2011 1 commit
    • Simon Marlow's avatar
      Merge in new code generator branch. · 889c084e
      Simon Marlow authored
      This changes the new code generator to make use of the Hoopl package
      for dataflow analysis.  Hoopl is a new boot package, and is maintained
      in a separate upstream git repository (as usual, GHC has its own
      lagging darcs mirror in http://darcs.haskell.org/packages/hoopl).
      
      During this merge I squashed recent history into one patch.  I tried
      to rebase, but the history had some internal conflicts of its own
      which made rebase extremely confusing, so I gave up. The history I
      squashed was:
      
        - Update new codegen to work with latest Hoopl
        - Add some notes on new code gen to cmm-notes
        - Enable Hoopl lag package.
        - Add SPJ note to cmm-notes
        - Improve GC calls on new code generator.
      
      Work in this branch was done by:
         - Milan Straka <fox@ucw.cz>
         - John Dias <dias@cs.tufts.edu>
         - David Terei <davidterei@gmail.com>
      
      Edward Z. Yang <ezyang@mit.edu> merged in further changes from GHC HEAD
      and fixed a few bugs.
      889c084e
  18. 07 Jul, 2010 2 commits
  19. 21 Jun, 2010 3 commits
  20. 18 Jun, 2010 1 commit
    • dterei's avatar
      Add support of TNTC to llvm backend · 24a3fee9
      dterei authored
      We do this through a gnu as feature called subsections,
      where you can put data/code into a numbered subsection
      and those subsections will be joined together in descending
      order by gas at compile time.
      24a3fee9
  21. 15 Jun, 2010 1 commit