This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 30 Oct, 2017 1 commit
    • Michal Terepeta's avatar
      Allow packing constructor fields · cca2d6b7
      Michal Terepeta authored
      This is another step for fixing #13825 and is based on D38 by Simon
      Marlow.
      
      The change allows storing multiple constructor fields within the same
      word. This currently applies only to `Float`s, e.g.,
      ```
      data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Float
      ```
      on 64-bit arch, will now store both fields within the same constructor
      word. For `WordX/IntX` we'll need to introduce new primop types.
      
      Main changes:
      
      - We now use sizes in bytes when we compute the offsets for
        constructor fields in `StgCmmLayout` and introduce padding if
        necessary (word-sized fields are still word-aligned)
      
      - `ByteCodeGen` had to be updated to correctly construct the data
        types. This required some new bytecode instructions to allow pushing
        things that are not full words onto the stack (and updating
        `Interpreter.c`). Note that we only use the packed stuff when
        constructing data types (i.e., for `PACK`), in all other cases the
        behavior should not change.
      
      - `RtClosureInspect` was changed to handle the new layout when
        extracting subterms. This seems to be used by things like `:print`.
        I've also added a test for this.
      
      - I deviated slightly from Simon's approach and use `PrimRep` instead
        of `ArgRep` for computing the size of fields.  This seemed more
        natural and in the future we'll probably want to introduce new
        primitive types (e.g., `Int8#`) and `PrimRep` seems like a better
        place to do that (where we already have `Int64Rep` for example).
        `ArgRep` on the other hand seems to be more focused on calling
        functions.
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      
      Test Plan: ./validate
      
      Reviewers: bgamari, simonmar, austin, hvr, goldfire, erikd
      
      Reviewed By: bgamari
      
      Subscribers: maoe, rwbarton, thomie
      
      GHC Trac Issues: #13825
      
      Differential Revision: https://phabricator.haskell.org/D3809
      cca2d6b7
  2. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  3. 06 Nov, 2014 1 commit
  4. 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
  5. 23 Sep, 2013 4 commits
  6. 10 Sep, 2013 1 commit
  7. 06 Aug, 2013 2 commits
    • gmainland's avatar
      Only use real XMM registers when assigning arguments. · 3e598fe0
      gmainland authored
      My original change to the calling convention mistakenly used all 6 XMM
      registers---which live in the global register table---on x86 (32 bit). This
      royally screwed up the floating point code generated for that platform because
      floating point arguments were passed in global registers instead of on the
      stack!
      3e598fe0
    • gmainland's avatar
      Rename SSE -> XMM for consistency. · 253a5b75
      gmainland authored
      We were using SSE is some places and XMM in others. Better to keep a consistent
      naming scheme.
      253a5b75
  8. 06 Apr, 2013 1 commit
  9. 01 Feb, 2013 2 commits
  10. 13 Nov, 2012 1 commit
    • Simon Marlow's avatar
      Fix the Slow calling convention (#7192) · 4270d7e7
      Simon Marlow authored
      The Slow calling convention passes the closure in R1, but we were
      ignoring this and hoping it would work, which it often did.  However,
      this bug seems to have been the cause of #7192, because the
      graph-colouring allocator is more sensitive to having correct liveness
      information on jumps.
      4270d7e7
  11. 30 Oct, 2012 1 commit
    • gmainlan@microsoft.com's avatar
      Draw STG F and D registers from the same pool of available SSE registers on x86-64. · e2f6bbd3
      gmainlan@microsoft.com authored
      On x86-64 F and D registers are both drawn from SSE registers, so there is no
      reason not to draw them from the same pool of available SSE registers. This
      means that whereas previously a function could only receive two Double arguments
      in registers even if it did not have any Float arguments, now it can receive up
      to 6 arguments that are any mix of Float and Double in registers.
      
      This patch breaks the LLVM back end. The next patch will fix this breakage.
      e2f6bbd3
  12. 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
  13. 16 Sep, 2012 1 commit
  14. 14 Sep, 2012 1 commit
  15. 12 Sep, 2012 1 commit
  16. 07 Aug, 2012 2 commits
  17. 06 Jul, 2012 1 commit
    • Simon Marlow's avatar
      Allow the register allocator access to argument regs (R1.., F1.., etc.) · f857f074
      Simon Marlow authored
      This was made possible by the recent change to codeGen to attach the
      live GlobalRegs to every CmmJump, and we'll be relying on it quite
      heavily in the new code generator too.
      
      What this means essentially is that when we see
      
        x = R1
      
      the register allocator will automatically assign x to R1 and generate
      no code at all (also known as "coalescing"). It wasn't possible before
      because the register allocator had to assume that R1 was always live,
      because it didn't have access to accurate liveness information.
      f857f074
  18. 05 Jul, 2012 1 commit
  19. 04 Nov, 2011 1 commit
  20. 13 Jun, 2011 2 commits
  21. 10 Jun, 2011 1 commit
  22. 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
  23. 18 Feb, 2011 1 commit
    • Edward Z. Yang's avatar
      New codegen: GC calling convention must use registers. · 4c53d93a
      Edward Z. Yang authored
      Previously, on register-deficient architectures like x86-32,
      the new code generator would emit code for calls to stg_gc_l1,
      stg_gc_d1 and stg_gc_f1 that pushed their single argument on
      to the stack, while the functions themselves expected the
      argument to live in L1, D1 and F1 (respectively).  This was
      because cmmCall with the GC calling convention allocated real
      registers, not virtual registers.
      
      This patch modifies the code for assigning registers/stack slots
      to use the right calling convention for GC and adds an assertion
      to ensure it did it properly.
      4c53d93a
  24. 18 Sep, 2009 2 commits
  25. 07 Jul, 2009 1 commit
  26. 03 Apr, 2009 1 commit
  27. 25 Mar, 2009 1 commit
  28. 23 Mar, 2009 5 commits