1. 16 Dec, 2014 1 commit
    • Peter Wortmann's avatar
      Source notes (Cmm support) · 7ceaf96f
      Peter Wortmann authored
      This patch adds CmmTick nodes to Cmm code. This is relatively
      straight-forward, but also not very useful, as many blocks will simply
      end up with no annotations whatosever.
      
      Notes:
      
      * We use this design over, say, putting ticks into the entry node of all
        blocks, as it seems to work better alongside existing optimisations.
        Now granted, the reason for this is that currently GHC's main Cmm
        optimisations seem to mainly reorganize and merge code, so this might
        change in the future.
      
      * We have the Cmm parser generate a few source notes as well. This is
        relatively easy to do - worst part is that it complicates the CmmParse
        implementation a bit.
      
      (From Phabricator D169)
      7ceaf96f
  2. 14 Dec, 2014 1 commit
    • Sergei Trofimovich's avatar
      powerpc: fix and enable shared libraries by default on linux · fa31e8f4
      Sergei Trofimovich authored
      Summary:
      And fix things all the way down to it. Namely:
          - remove 'r30' from free registers, it's an .LCTOC1 register
            for gcc. generated .plt stubs expect it to be initialised.
          - fix PicBase computation, which originally forgot to use 'tmp'
            reg in 'initializePicBase_ppc.fetchPC'
          - mark 'ForeighTarget's as implicitly using 'PicBase' register
            (see comment for details)
          - add 64-bit MO_Sub and test on alloclimit3/4 regtests
          - fix dynamic label offsets to match with .LCTOC1 offset
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Test Plan: validate passes equal amount of vanilla/dyn tests
      
      Reviewers: simonmar, erikd, austin
      
      Reviewed By: erikd, austin
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D560
      
      GHC Trac Issues: #8024, #9831
      fa31e8f4
  3. 08 Dec, 2014 1 commit
  4. 30 Nov, 2014 1 commit
  5. 21 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix Trac #9815 · 4ba4cc7a
      Simon Peyton Jones authored
      Dot-dot record-wildcard notation is simply illegal for constructors
      without any named fields, but that was neither documented nor checked.
      This patch does so
      
      - Make the check in RnPat
      - Add test T9815
      - Fix CmmLayoutStack which was using the illegal form (!)
      - Document in user manual
      4ba4cc7a
  6. 19 Nov, 2014 1 commit
  7. 13 Nov, 2014 1 commit
  8. 12 Nov, 2014 1 commit
  9. 06 Nov, 2014 1 commit
  10. 21 Oct, 2014 1 commit
    • Moritz Angermann's avatar
      Fixes the ARM build · 69f63612
      Moritz Angermann authored
      Summary:
      CodeGen.Platform.hs was changed with the following diff:
      
         -#endif
          globalRegMaybe _                        = Nothing
         +#elif MACHREGS_NO_REGS
         +globalRegMaybe _ = Nothing
         +#else
         +globalRegMaybe = panic "globalRegMaybe not defined for this platform"
         +#endif
      
      which causes globalRegMaybe ot panic for arch ARM.
      
      This patch ensures globalRegMaybe is not called on ARM.
      Signed-off-by: Moritz Angermann's avatarMoritz Angermann <moritz@lichtzwerge.de>
      
      Test Plan: Building arm cross-compiler (e.g. --target=arm-apple-darwin10)
      
      Reviewers: hvr, ezyang, simonmar, rwbarton, austin
      
      Reviewed By: austin
      
      Subscribers: dterei, bgamari, simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D208
      
      GHC Trac Issues: #9593
      69f63612
  11. 20 Oct, 2014 4 commits
  12. 19 Oct, 2014 1 commit
  13. 02 Oct, 2014 4 commits
    • Edward Z. Yang's avatar
      Rename _closure to _static_closure, apply naming consistently. · 35672072
      Edward Z. Yang authored
      Summary:
      In preparation for indirecting all references to closures,
      we rename _closure to _static_closure to ensure any old code
      will get an undefined symbol error.  In order to reference
      a closure foobar_closure (which is now undefined), you should instead
      use STATIC_CLOSURE(foobar).  For convenience, a number of these
      old identifiers are macro'd.
      
      Across C-- and C (Windows and otherwise), there were differing
      conventions on whether or not foobar_closure or &foobar_closure
      was the address of the closure.  Now, all foobar_closure references
      are addresses, and no & is necessary.
      
      CHARLIKE/INTLIKE were not changed, simply alpha-renamed.
      
      Part of remove HEAP_ALLOCED patch set (#8199)
      
      Depends on D265
      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/D267
      
      GHC Trac Issues: #8199
      35672072
    • Edward Z. Yang's avatar
      Properly generate info tables for static closures in C--. · 178eb906
      Edward Z. Yang authored
      Summary:
      Previously, we assumed all objects declared in C-- were not-static, even
      ones which were CONSTR_NOCAF_STATIC.  This used to be harmless, but now
      we need this information to be correct.
      
      Part of remove HEAP_ALLOCED patch set (#8199)
      
      Depends on D264
      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/D265
      
      GHC Trac Issues: #8199
      178eb906
    • Edward Z. Yang's avatar
      BC-breaking changes to C-- CLOSURE syntax. · 3b5a840b
      Edward Z. Yang authored
      Summary:
      Previously, there were two variants of CLOSURE in C--:
      
          - Top-level CLOSURE(foo_closure, foo, lits...), which defines a new
            static closure and gives it a name, and
      
          - Array CLOSURE(foo, lits...), which was used for the static char
            and integer arrays.
      
      They used the same name, were confusing, and didn't even generate
      the correct internal label representation!  So now, we have two
      new forms:
      
          - Top-level CLOSURE(foo, lits...) which automatically generates
            foo_closure (along with foo_info, which we were doing already)
      
          - Array ANONYMOUS_CLOSURE(foo, lits...) which doesn't generate
            a foo_closure identifier.
      
      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/D264
      
      GHC Trac Issues: #8199
      3b5a840b
    • 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
  14. 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
  15. 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
  16. 05 Sep, 2014 1 commit
    • Sergei Trofimovich's avatar
      pprC: declare extern cmm primitives as functions, not data · e18525fa
      Sergei Trofimovich authored
      Summary:
        The commit fixes incorrect code generation of
        integer-gmp package on ia64 due to C prototypes mismatch.
        Before the patch prototypes for "foreign import prim" were:
            StgWord poizh[];
        After the patch they became:
            StgFunPtr poizh();
      
      Long story:
      
      Consider the following simple example:
      
          {-# LANGUAGE MagicHash, GHCForeignImportPrim, UnliftedFFITypes #-}
          module M where
          import GHC.Prim -- Int#
          foreign import prim "poizh" poi# :: Int# -> Int#
      
      Before the patch unregisterised build generated the
      following 'poizh' reference:
          EI_(poizh); /* StgWord poizh[]; */
          FN_(M_poizh_entry) {
          // ...
          JMP_((W_)&poizh);
          }
      
      After the patch it looks this way:
          EF_(poizh); /* StgFunPtr poizh(); */
          FN_(M_poizh_entry) {
          // ...
          JMP_((W_)&poizh);
          }
      
      On ia64 it leads to different relocation types being generated:
        incorrect one:
          addl r14 = @ltoffx(poizh#)
          ld8.mov r14 = [r14], poizh# ; r14 = address-of 'poizh#'
        correct one:
          addl r14 = @ltoff(@fptr(poizh#)), gp ; r14 = address-of-thunk 'poizh#'
          ld8 r14 = [r14]
      
      '@fptr(poizh#)' basically instructs assembler to creates
      another obect consisting of real address to 'poizh' instructions
      and module address. That '@fptr' object is used as a function "address"
      This object is different for every module referencing 'poizh' symbol.
      
      All indirect function calls expect '@fptr' object. That way
      call site reads real destination address and set destination
      module address in 'gp' register from '@fptr'.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      e18525fa
  17. 31 Aug, 2014 1 commit
  18. 28 Aug, 2014 1 commit
  19. 26 Aug, 2014 1 commit
    • Sergei Trofimovich's avatar
      UNREG: fix emission of large Integer literals in C codegen · 43f1b2ec
      Sergei Trofimovich authored
      Summary:
      On amd64/UNREG build there is many failing tests trying
      to deal with 'Integer' types.
      
      Looking at 'integerConversions' test I've observed
      invalid C code generated by GHC.
      
      Cmm code
          CInt a = -1; (a == -1)
      yields 'False' with optimisations enabled via the following C code:
          StgWord64 a = (StgWord32)0xFFFFffffFFFFffffu; (a == 0xFFFFffffFFFFffffu)
      
      The patch fixes it by shrinking emitted literals to required sizes:
          StgWord64 a = (StgWord32)0xFFFFffffu; (a == 0xFFFFffffu)
      
      Thanks to Reid Barton for tracking down and fixing the issue.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Test Plan: validate on UNREG build (amd64, x86)
      
      Reviewers: simonmar, rwbarton, austin
      
      Subscribers: hvr, simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D173
      43f1b2ec
  20. 23 Aug, 2014 1 commit
    • rwbarton's avatar
      Add MO_AddIntC, MO_SubIntC MachOps and implement in X86 backend · cfd08a99
      rwbarton authored
      Summary:
      These MachOps are used by addIntC# and subIntC#, which in turn are
      used in integer-gmp when adding or subtracting small Integers. The
      following benchmark shows a ~6% speedup after this commit on x86_64
      (building GHC with BuildFlavour=perf).
      
          {-# LANGUAGE MagicHash #-}
      
          import GHC.Exts
          import Criterion.Main
      
          count :: Int -> Integer
          count (I# n#) = go n# 0
            where go :: Int# -> Integer -> Integer
                  go 0# acc = acc
                  go n# acc = go (n# -# 1#) $! acc + 1
      
          main = defaultMain [bgroup "count"
                                [bench "100" $ whnf count 100]]
      
      Differential Revision: https://phabricator.haskell.org/D140
      cfd08a99
  21. 19 Aug, 2014 1 commit
    • Austin Seipp's avatar
      build: require GHC 7.6 for bootstrapping · 527bcc41
      Austin Seipp authored
      Summary:
      Per the usual standards, a build of GHC is only compileable
      by the last two releases (e.g. 7.8 only by 7.4 and 7.6). To make sure
      we don't get suckered into supporting older compilers, let's remove
      this support now.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan:
      Try to bootstrap with GHC 7.4, watch it fail. Bootstrap
      with 7.6 or better, and everything works.
      
      Reviewers: hvr
      
      Reviewed By: hvr
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D167
      527bcc41
  22. 14 Aug, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement new CLZ and CTZ primops (re #9340) · e0c1767d
      Herbert Valerio Riedel authored
      This implements the new primops
      
        clz#, clz32#, clz64#,
        ctz#, ctz32#, ctz64#
      
      which provide efficient implementations of the popular
      count-leading-zero and count-trailing-zero respectively
      (see testcase for a pure Haskell reference implementation).
      
      On x86, NCG as well as LLVM generates code based on the BSF/BSR
      instructions (which need extra logic to make the 0-case well-defined).
      
      Test Plan: validate and succesful tests on i686 and amd64
      
      Reviewers: rwbarton, simonmar, ezyang, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D144
      
      GHC Trac Issues: #9340
      e0c1767d
  23. 12 Aug, 2014 2 commits
    • tibbe's avatar
      Add some Haddocks to SMRep · a6fd7b5c
      tibbe authored
      a6fd7b5c
    • tibbe's avatar
      shouldInlinePrimOp: Fix Int overflow · 6f862dfa
      tibbe authored
      There were two overflow issues in shouldInlinePrimOp. The first one is
      due to a negative CmmInt literal being created if the array size was
      given as larger than 2^63-1 (on a 64-bit platform.) This meant that
      large array sizes could compare as being smaller than
      maxInlineAllocSize.
      
      The second issue is that we casted the Integer to an Int in the
      comparison, which again meant that large array sizes could compare as
      being smaller than maxInlineAllocSize.
      
      The attempt to allocate a large array inline then caused a segfault.
      
      Fixes #9416.
      6f862dfa
  24. 01 Aug, 2014 4 commits
  25. 31 Jul, 2014 1 commit
  26. 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
  27. 20 Jul, 2014 2 commits
  28. 02 Jul, 2014 1 commit
    • rwbarton's avatar
      Mark HPC ticks labels as dynamic · 3285a3d5
      rwbarton authored
      This enables GHC's PIC machinery for accessing tickboxes of other
      packages correctly when building dynamic libraries. Previously
      GHC was doing strange and wrong things in that situation. See #9012.
      3285a3d5
  29. 30 Jun, 2014 1 commit
    • tibbe's avatar
      Re-add more primops for atomic ops on byte arrays · 4ee4ab01
      tibbe authored
      This is the second attempt to add this functionality. The first
      attempt was reverted in 950fcae4, due
      to register allocator failure on x86. Given how the register
      allocator currently works, we don't have enough registers on x86 to
      support cmpxchg using complicated addressing modes. Instead we fall
      back to a simpler addressing mode on x86.
      
      Adds the following primops:
      
       * atomicReadIntArray#
       * atomicWriteIntArray#
       * fetchSubIntArray#
       * fetchOrIntArray#
       * fetchXorIntArray#
       * fetchAndIntArray#
      
      Makes these pre-existing out-of-line primops inline:
      
       * fetchAddIntArray#
       * casIntArray#
      4ee4ab01