1. 18 Dec, 2015 1 commit
    • Ömer Sinan Ağacan's avatar
      LLVM backend: Show expected LLVM version in warnings/errors · 0e9a331f
      Ömer Sinan Ağacan authored
      Summary:
      Before:
      
          [1 of 1] Compiling Main             ( Main.hs, Main.o )
          You are using a new version of LLVM that hasn't been tested yet!
          We will try though...
      
      After:
      
          [1 of 1] Compiling Main             ( Main.hs, Main.o )
          You are using an unsupported version of LLVM!
          Currently only 3.7 is supported.
          We will try though...
      
      Before:
      
          [1 of 1] Compiling Main             ( Main.hs, Main.o )
      
          <no location info>:
              Warning: Couldn't figure out LLVM version!
                       Make sure you have installed LLVM
          ghc: could not execute: opt
      
      After:
      
          [1 of 1] Compiling Main             ( Main.hs, Main.o )
      
          <no location info>: error:
              Warning: Couldn't figure out LLVM version!
                       Make sure you have installed LLVM 3.7
          ghc-stage1: could not execute: opt
      
      Reviewers: austin, rwbarton, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1658
      0e9a331f
  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. 17 Oct, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make Monad/Applicative instances MRP-friendly · e8ed2136
      Herbert Valerio Riedel authored
      This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e.
      such that the explicit definitions for `return` and `(>>)` match the
      MRP-style default-implementation, i.e.
      
        return = pure
      
      and
      
        (>>) = (*>)
      
      This way, e.g. all `return = pure` definitions can easily be grepped and
      removed in GHC 8.1;
      
      Test Plan: Harbormaster
      
      Reviewers: goldfire, alanz, bgamari, quchen, austin
      
      Reviewed By: quchen, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1312
      e8ed2136
  4. 13 Oct, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Switch to LLVM version 3.7 · 29310b62
      Erik de Castro Lopo authored
      Before this commit, GHC only supported LLVM 3.6. Now it only supports
      LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier
      do not work on AArch64/Arm64, but 3.7 does.
      
      Also:
      * Add CC_Ghc constructor to LlvmCallConvention.
      * Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with
        a single `supportedLlvmVersion` variable.
      * Get `supportedLlvmVersion` from version specified in configure.ac.
      * Drop llvmVersion field from DynFlags (no longer needed because only
        one version is supported).
      
      Test Plan: Validate on x86_64 and arm
      
      Reviewers: bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1320
      
      GHC Trac Issues: #10953
      29310b62
  5. 09 Oct, 2015 2 commits
  6. 14 Apr, 2015 1 commit
  7. 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
  8. 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
  9. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      
      
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  10. 05 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the ...
      66218d15
  11. 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
  12. 09 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Re-work the naming story for the GHCi prompt (Trac #8649) · 73c08ab1
      Simon Peyton Jones authored
      The basic idea here is simple, and described in Note [The interactive package]
      in HscTypes, which starts thus:
      
          Note [The interactive package]
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Type and class declarations at the command prompt are treated as if
          they were defined in modules
             interactive:Ghci1
             interactive:Ghci2
             ...etc...
          with each bunch of declarations using a new module, all sharing a
          common package 'interactive' (see Module.interactivePackageId, and
          PrelNames.mkInteractiveModule).
      
          This scheme deals well with shadowing.  For example:
      
             ghci> data T = A
             ghci> data T = B
             ghci> :i A
             data Ghci1.T = A  -- Defined at <interactive>:2:10
      
          Here we must display info about constructor A, but its type T has been
          shadowed by the second declaration.  But it has a respectable
          qualified name (Ghci1.T), and its source location says where it was
          defined.
      
          So the main invariant continues to hold, that in any session an original
          name M.T only refers to oe unique thing.  (In a previous iteration both
          the T's above were called :Interactive.T, albeit with different uniques,
          which gave rise to all sorts of trouble.)
      
      This scheme deals nicely with the original problem.  It allows us to
      eliminate a couple of grotseque hacks
        - Note [Outputable Orig RdrName] in HscTypes
        - Note [interactive name cache] in IfaceEnv
      (both these comments have gone, because the hacks they describe are no
      longer necessary). I was also able to simplify Outputable.QueryQualifyName,
      so that it takes a Module/OccName as args rather than a Name.
      
      However, matters are never simple, and this change took me an
      unreasonably long time to get right.  There are some details in
      Note [The interactive package] in HscTypes.
      73c08ab1
  13. 23 Sep, 2013 2 commits
  14. 11 Sep, 2013 1 commit
  15. 14 Aug, 2013 1 commit
  16. 27 Jun, 2013 4 commits
    • Peter Wortmann's avatar
      LLVM refactor cleanups · fe44d053
      Peter Wortmann authored
      Slightly more documentation, removed unused label map (huh),
      removed MonadIO instance on LlvmM to improve encapsulation.
      fe44d053
    • 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
    • Peter Wortmann's avatar
      Use SDoc for all LLVM pretty-printing · 99d39221
      Peter Wortmann authored
      This patch reworks some parts of the LLVM pretty-printing code that were
      still using Show and String. Now we should be using SDoc and Outputable
      throughout. Note that many get*Name functions become pp*Name
      here as a side-effect.
      99d39221
  17. 01 Feb, 2013 2 commits
  18. 19 Jan, 2013 1 commit
    • dterei's avatar
      Up supported LLVM version to 3.3. · fb93d791
      dterei authored
      Actual support is in progress but we will accept bugs against these
      version. LLVM 3.2 seems in good shape at this point anyway.
      fb93d791
  19. 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
  20. 30 Oct, 2012 1 commit
    • gmainlan@microsoft.com's avatar
      Generate correct LLVM for the new register allocation scheme. · dcf88e66
      gmainlan@microsoft.com authored
      We now have accurate global register liveness information attached to all Cmm
      procedures and jumps. With this patch, the LLVM back end uses this information
      to pass only the live floating point (F and D) registers on tail calls. This
      makes the LLVM back end compatible with the new register allocation strategy.
      
      Ideally the GHC LLVM calling convention would put all registers that are always
      live first in the parameter sequence. Unfortunately the specification is written
      so that on x86-64 SpLim (always live) is passed after the R registers. Therefore
      we must always pass *something* in the R registers, so we pass the LLVM value
      undef.
      dcf88e66
  21. 19 Oct, 2012 1 commit
    • Simon Marlow's avatar
      Remove the old codegen · 6fbd46b0
      Simon Marlow authored
      Except for CgUtils.fixStgRegisters that is used in the NCG and LLVM
      backends, and should probably be moved somewhere else.
      6fbd46b0
  22. 16 Sep, 2012 2 commits
  23. 12 Sep, 2012 1 commit
  24. 21 Aug, 2012 2 commits
  25. 07 Aug, 2012 1 commit
  26. 25 Jun, 2012 1 commit
  27. 12 Jun, 2012 1 commit
  28. 13 Jan, 2012 1 commit
  29. 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.
      fe60dd4a
  30. 04 Dec, 2011 2 commits
  31. 02 Oct, 2011 1 commit