1. 03 Jul, 2015 1 commit
    • Peter Trommler's avatar
      Implement PowerPC 64-bit native code backend for Linux · d3c1dda6
      Peter Trommler authored
      Extend the PowerPC 32-bit native code generator for "64-bit
      PowerPC ELF Application Binary Interface Supplement 1.9" by
      Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
      OpenPOWER ABI for Linux Supplement" by IBM.
      The latter ABI is mainly used on POWER7/7+ and POWER8
      Linux systems running in little-endian mode. The code generator
      supports both static and dynamic linking. PowerPC 64-bit
      code for ELF ABI 1.9 and 2 is mostly position independent
      anyway, and thus so is all the code emitted by the code
      generator. In other words, -fPIC does not make a difference.
      
      rts/stg/SMP.h support is implemented.
      
      Following the spirit of the introductory comment in
      PPC/CodeGen.hs, the rest of the code is a straightforward
      extension of the 32-bit implementation.
      
      Limitations:
      * Code is generated only in the medium code model, which
        is also gcc's default
      * Local symbols are not accessed directly, which seems to
        also be the case for 32-bit
      * LLVM does not work, but this does not work on 32-bit either
      * Must use the system runtime linker in GHCi, because the
        GHC linker for "static" object files (rts/Linker.c) for
        PPC 64-bit is not implemented. The system runtime
        (dynamic) linker works.
      * The handling of the system stack (register 1) is not ELF-
        compliant so stack traces break. Instead of allocating a new
        stack frame, spill code should use the "official" spill area
        in the current stack frame and deallocation code should restore
        the back chain
      * DWARF support is missing
      
      Fixes #9863
      
      Test Plan: validate (on powerpc, too)
      
      Reviewers: simonmar, trofi, erikd, austin
      
      Reviewed By: trofi
      
      Subscribers: bgamari, arnons1, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D629
      
      GHC Trac Issues: #9863
      d3c1dda6
  2. 16 May, 2015 1 commit
  3. 17 Dec, 2014 2 commits
    • Peter Wortmann's avatar
      Generate DWARF info section · cc481ec8
      Peter Wortmann authored
      This is where we actually make GHC emit DWARF code. The info section
      contains all the general meta information bits as well as an entry for
      every block of native code.
      
      Notes:
      
      * We need quite a few new labels in order to properly address starts
        and ends of blocks.
      
      * Thanks to Nathan Howell for taking the iniative to get our own Haskell
        language ID for DWARF!
      
      (From Phabricator D396)
      cc481ec8
    • Peter Wortmann's avatar
      Generate .loc/.file directives from source ticks · 64678e9e
      Peter Wortmann authored
      This generates DWARF, albeit indirectly using the assembler. This is
      the easiest (and, apparently, quite standard) method of generating the
      .debug_line DWARF section.
      
      Notes:
      
      * Note we have to make sure that .file directives appear correctly
        before the respective .loc. Right now we ppr them manually, which makes
        them absent from dumps. Fixing this would require .file to become a
        native instruction.
      
      * We have to pass a lot of things around the native code generator. I
        know Ian did quite a bit of refactoring already, but having one common
        monad could *really* simplify things here...
      
      * To support SplitObjcs, we need to emit/reset all DWARF data at every
        split. We use the occassion to move split marker generation to
        cmmNativeGenStream as well, so debug data extraction doesn't have to
        choke on it.
      
      (From Phabricator D396)
      64678e9e
  4. 16 Dec, 2014 1 commit
    • Peter Wortmann's avatar
      Debug data extraction (NCG support) · f46aa733
      Peter Wortmann authored
      The purpose of the Debug module is to collect all required information
      to generate debug information (DWARF etc.) in the back-ends. Our main
      data structure is the "debug block", which carries all information we have
      about a block of code that is going to get produced.
      
      Notes:
      
      * Debug blocks are arranged into a tree according to tick scopes. This
        makes it easier to reason about inheritance rules. Note however that
        tick scopes are not guaranteed to form a tree, which requires us to
        "copy" ticks to not lose them.
      
      * This is also where we decide what source location we regard as
        representing a code block the "best". The heuristic is basically that
        we want the most specific source reference that comes from the same file
        we are currently compiling. This seems to be the most useful choice in
        my experience.
      
      * We are careful to not be too lazy so we don't end up breaking streaming.
        Debug data will be kept alive until the end of codegen, after all.
      
      * We change native assembler dumps to happen right away for every Cmm group.
        This simplifies the code somewhat and is consistent with how pretty much
        all of GHC handles dumps with respect to streamed code.
      
      (From Phabricator D169)
      f46aa733
  5. 30 Nov, 2014 1 commit
  6. 04 Nov, 2014 1 commit
  7. 27 Sep, 2014 1 commit
    • thomie's avatar
      Stop exporting, and stop using, functions marked as deprecated · 51aa2fa3
      thomie authored
      Don't export `getUs` and `getUniqueUs`. `UniqSM` has a `MonadUnique` instance:
      
          instance MonadUnique UniqSM where
              getUniqueSupplyM = getUs
              getUniqueM  = getUniqueUs
              getUniquesM = getUniquesUs
      
      Commandline-fu used:
      
          git grep -l 'getUs\>' |
              grep -v compiler/basicTypes/UniqSupply.lhs |
              xargs sed -i 's/getUs/getUniqueSupplyM/g
      
          git grep -l 'getUniqueUs\>' |
              grep -v combiler/basicTypes/UniqSupply.lhs |
              xargs sed -i 's/getUniqueUs/getUniqueM/g'
      
      Follow up on b522d3a3
      
      Reviewed By: austin, hvr
      
      Differential Revision: https://phabricator.haskell.org/D220
      51aa2fa3
  8. 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
  9. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265
      
       we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
  10. 11 Jun, 2014 1 commit
  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. 22 Apr, 2014 1 commit
  13. 16 Jan, 2014 1 commit
  14. 11 Sep, 2013 1 commit
  15. 06 Sep, 2013 1 commit
    • thoughtpolice's avatar
      Add basic support for GHCJS · b372e8ea
      thoughtpolice authored
      
      
      This patch encompasses most of the basic infrastructure for GHCJS. It
      includes:
      
        * A new extension, -XJavaScriptFFI
        * A new architecture, ArchJavaScript
        * Parser and lexer support for 'foreign import javascript', only
          available under -XJavaScriptFFI, using ArchJavaScript.
        * As a knock-on, there is also a new 'WayCustom' constructor in
          DynFlags, so clients of the GHC API can add custom 'tags' to their
          built files. This should be useful for other users as well.
      
      The remaining changes are really just the resulting fallout, making sure
      all the cases are handled appropriately for DynFlags and Platform.
      Authored-by: Luite Stegeman's avatarLuite Stegeman <stegeman@gmail.com>
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      b372e8ea
  16. 13 May, 2013 2 commits
  17. 09 Mar, 2013 1 commit
  18. 02 Feb, 2013 2 commits
  19. 07 Jan, 2013 1 commit
    • Simon Marlow's avatar
      Fix bugs in allocMoreStack (#7498, #7510) · 03d360f2
      Simon Marlow authored
      There were four bugs here.  Clearly I didn't test this enough to
      expose the bugs - it appeared to work on x86/Linux, but completely by
      accident it seems.
      
      1. the delta was wrong by a factor of the slot size (as noted on #7498)
      
      2. we weren't correctly aligning the stack pointer (sp needs to be
      16-byte aligned on x86/x86_64)
      
      3. we were doing the adjustment multiple times in the case of a block
      that was both a return point and a local branch target.  To fix this I
      had to add new shim blocks to adjust the stack pointer, and retarget
      the original branches.  See comment for details.
      
      4. we were doing the adjustment for CALL instructions, which is
      unnecessary and wrong; only JMPs should be preceded by a stack
      adjustment.
      
      (Someone with a PPC box will need to update the PPC version of
      allocMoreStack to fix the above bugs, using the x86 version as a
      guide.)
      03d360f2
  20. 16 Dec, 2012 1 commit
  21. 15 Dec, 2012 1 commit
  22. 12 Dec, 2012 2 commits
  23. 11 Dec, 2012 5 commits
  24. 06 Dec, 2012 1 commit
  25. 13 Nov, 2012 1 commit
    • ian@well-typed.com's avatar
      Tell the compiler about alpha, mipseb and mipsel again; fixes #7339 · 9756690f
      ian@well-typed.com authored
      This reverts the compiler parts of
      
          commit 7b594a5d
          Author: David Terei <davidterei@gmail.com>
          Date:   Mon Nov 21 12:05:18 2011 -0800
      
          Remove registerised code for dead architectures: mips, ia64, alpha,
          hppa1, m68k
      
      In particular, we want to know whether bewareLoadStoreAlignment should
      return True or False for them.
      
      It also reverts
      
          commit 3fc68b5c
          Author: Simon Marlow <marlowsd@gmail.com>
          Date:   Wed Jan 4 11:44:02 2012 +0000
      
          Remove missing archs (mipseb, mipsel, alpha) (#5734)
      
          It doesn't hurt to map these to ArchUnknown since we don't need to
          know anything specific about them, and adding them would be a pain
          (there are a bunch of places where we have to case-match on all the
          arches to avoid warnings).
      9756690f
  26. 12 Nov, 2012 2 commits
    • Simon Marlow's avatar
      Fix warnings · 92957808
      Simon Marlow authored
      92957808
    • 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
  27. 30 Oct, 2012 1 commit
  28. 18 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Refactor the way dump flags are handled · d4a19643
      ian@well-typed.com authored
      We were being inconsistent about how we tested whether dump flags
      were enabled; in particular, sometimes we also checked the verbosity,
      and sometimes we didn't.
      
      This lead to oddities such as "ghc -v4" printing an "Asm code" section
      which didn't contain any code, and "-v4" enabled some parts of
      "-ddump-deriv" but not others.
      
      Now all the tests use dopt, which also takes the verbosity into account
      as appropriate.
      d4a19643
  29. 16 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Some alpha renaming · cd33eefd
      ian@well-typed.com authored
      Mostly d -> g (matching DynFlag -> GeneralFlag).
      Also renamed if* to when*, matching the Haskell if/when names
      cd33eefd
  30. 08 Oct, 2012 1 commit
    • Simon Marlow's avatar
      Produce new-style Cmm from the Cmm parser · a7c0387d
      Simon Marlow authored
      The main change here is that the Cmm parser now allows high-level cmm
      code with argument-passing and function calls.  For example:
      
      foo ( gcptr a, bits32 b )
      {
        if (b > 0) {
           // we can make tail calls passing arguments:
           jump stg_ap_0_fast(a);
        }
      
        return (x,y);
      }
      
      More details on the new cmm syntax are in Note [Syntax of .cmm files]
      in CmmParse.y.
      
      The old syntax is still more-or-less supported for those occasional
      code fragments that really need to explicitly manipulate the stack.
      However there are a couple of differences: it is now obligatory to
      give a list of live GlobalRegs on every jump, e.g.
      
        jump %ENTRY_CODE(Sp(0)) [R1];
      
      Again, more details in Note [Syntax of .cmm files].
      
      I have rewritten most of the .cmm files in the RTS into the new
      syntax, except for AutoApply.cmm which is generated by the genapply
      program: this file could be generated in the new syntax instead and
      would probably be better off for it, but I ran out of enthusiasm.
      
      Some other changes in this batch:
      
       - The PrimOp calling convention is gone, primops now use the ordinary
         NativeNodeCall convention.  This means that primops and "foreign
         import prim" code must be written in high-level cmm, but they can
         now take more than 10 arguments.
      
       - CmmSink now does constant-folding (should fix #7219)
      
       - .cmm files now go through the cmmPipeline, and as a result we
         generate better code in many cases.  All the object files generated
         for the RTS .cmm files are now smaller.  Performance should be
         better too, but I haven't measured it yet.
      
       - RET_DYN frames are removed from the RTS, lots of code goes away
      
       - we now have some more canned GC points to cover unboxed-tuples with
         2-4 pointers, which will reduce code size a little.
      a7c0387d
  31. 25 Sep, 2012 1 commit