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. 10 Apr, 2015 1 commit
  2. 20 Jan, 2015 1 commit
  3. 16 Dec, 2014 1 commit
    • Peter Wortmann's avatar
      Add unwind information to Cmm · 711a51ad
      Peter Wortmann authored
      Unwind information allows the debugger to discover more information
      about a program state, by allowing it to "reconstruct" other states of
      the program. In practice, this means that we explain to the debugger
      how to unravel stack frames, which comes down mostly to explaining how
      to find their Sp and Ip register values.
      
      * We declare yet another new constructor for CmmNode - and this time
        there's actually little choice, as unwind information can and will
        change mid-block. We don't actually make use of these capabilities,
        and back-end support would be tricky (generate new labels?), but it
        feels like the right way to do it.
      
      * Even though we only use it for Sp so far, we allow CmmUnwind to specify
        unwind information for any register. This is pretty cheap and could
        come in useful in future.
      
      * We allow full CmmExpr expressions for specifying unwind values. The
        advantage here is that we don't have to make up new syntax, and can e.g.
        use the WDS macro directly. On the other hand, the back-end will now
        have to simplify the expression until it can sensibly be converted
        into DWARF byte code - a process which might fail, yielding NCG panics.
        On the other hand, when you're writing Cmm by hand you really ought to
        know what you're doing.
      
      (From Phabricator D169)
      711a51ad
  4. 20 Oct, 2014 1 commit
  5. 02 Oct, 2014 1 commit
    • 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
  6. 20 Jul, 2014 1 commit
  7. 16 Jan, 2014 1 commit
    • Simon Marlow's avatar
      Add a way to reserve temporary stack space in high-level Cmm · eaa37a0f
      Simon Marlow authored
      We occasionally need to reserve some temporary memory in a primop for
      passing to a foreign function.  We've been using the stack for this,
      but when we moved to high-level Cmm it became quite fragile because
      primops are in high-level Cmm and the stack is supposed to be under
      the control of the Cmm pipeline.
      
      So this change puts things on a firmer footing by adding a new Cmm
      construct 'reserve'.  e.g. in decodeFloat_Int#:
      
          reserve 2 = tmp {
      
            mp_tmp1  = tmp + WDS(1);
            mp_tmp_w = tmp;
      
            /* Perform the operation */
            ccall __decodeFloat_Int(mp_tmp1 "ptr", mp_tmp_w "ptr", arg);
      
            r1 = W_[mp_tmp1];
            r2 = W_[mp_tmp_w];
          }
      
      reserve is described in CmmParse.y.
      
      Unfortunately the argument to reserve must be a compile-time constant.
      We might have to extend the parser to allow expressions with
      arithmetic operators if this is too restrictive.
      
      Note also that the return instruction for the procedure must be
      outside the scope of the reserved stack area, so we have to extract
      the values from the reserved area before we close the scope.  This
      means some more local variables (r1, r2 in the example above).  The
      generated code is more or less identical to what we had before though.
      eaa37a0f
  8. 01 Oct, 2013 1 commit
  9. 23 Sep, 2013 2 commits
  10. 01 Feb, 2013 1 commit
  11. 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
  12. 29 Nov, 2011 1 commit
    • Simon Marlow's avatar
      Make profiling work with multiple capabilities (+RTS -N) · 50de6034
      Simon Marlow authored
      This means that both time and heap profiling work for parallel
      programs.  Main internal changes:
      
        - CCCS is no longer a global variable; it is now another
          pseudo-register in the StgRegTable struct.  Thus every
          Capability has its own CCCS.
      
        - There is a new built-in CCS called "IDLE", which records ticks for
          Capabilities in the idle state.  If you profile a single-threaded
          program with +RTS -N2, you'll see about 50% of time in "IDLE".
      
        - There is appropriate locking in rts/Profiling.c to protect the
          shared cost-centre-stack data structures.
      
      This patch does enough to get it working, I have cut one big corner:
      the cost-centre-stack data structure is still shared amongst all
      Capabilities, which means that multiple Capabilities will race when
      updating the "allocations" and "entries" fields of a CCS.  Not only
      does this give unpredictable results, but it runs very slowly due to
      cache line bouncing.
      
      It is strongly recommended that you use -fno-prof-count-entries to
      disable the "entries" count when profiling parallel programs. (I shall
      add a note to this effect to the docs).
      50de6034
  13. 25 Oct, 2011 1 commit
  14. 05 Aug, 2011 1 commit
  15. 09 Jun, 2011 1 commit
    • Ian Lynagh's avatar
      Refactor SrcLoc and SrcSpan · b2bd63f9
      Ian Lynagh authored
      The "Unhelpful" cases are now in a separate type. This allows us to
      improve various things, e.g.:
      * Most of the panic's in SrcLoc are now gone
      * The Lexer now works with RealSrcSpans rather than SrcSpans, i.e. it
        knows that it has real locations and thus can assume that the line
        number etc really exists
      * Some of the more suspicious cases are no longer necessary, e.g.
        we no longer need this case in advanceSrcLoc:
            advanceSrcLoc loc _ = loc -- Better than nothing
      
      More improvements can probably be made, e.g. tick locations can
      probably use RealSrcSpans too.
      b2bd63f9
  16. 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
  17. 12 Nov, 2010 1 commit
  18. 05 Aug, 2010 1 commit
  19. 15 Jul, 2010 1 commit
  20. 10 Dec, 2009 1 commit
    • Simon Marlow's avatar
      Fix #3741, simplifying things in the process · f4b72748
      Simon Marlow authored
      The problem in #3741 was that we had confused column numbers with byte
      offsets, which fails in the case of UTF-8 (amongst other things).
      Fortunately we're tracking correct column offsets now, so we didn't
      have to make a calculation based on a byte offset.  I got rid of two
      fields from the PState (last_line_len and last_offs).and one field
      from the AI (alex input) constructor.
      f4b72748
  21. 27 Nov, 2009 1 commit
  22. 29 Oct, 2009 1 commit
  23. 14 May, 2009 1 commit
  24. 24 Apr, 2009 1 commit
  25. 14 Aug, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      Merging in the new codegen branch · 176fa33f
      dias@eecs.harvard.edu authored
      This merge does not turn on the new codegen (which only compiles
      a select few programs at this point),
      but it does introduce some changes to the old code generator.
      
      The high bits:
      1. The Rep Swamp patch is finally here.
         The highlight is that the representation of types at the
         machine level has changed.
         Consequently, this patch contains updates across several back ends.
      2. The new Stg -> Cmm path is here, although it appears to have a
         fair number of bugs lurking.
      3. Many improvements along the CmmCPSZ path, including:
         o stack layout
         o some code for infotables, half of which is right and half wrong
         o proc-point splitting
      176fa33f
  26. 04 Sep, 2007 1 commit
  27. 03 Sep, 2007 1 commit
  28. 01 Sep, 2007 1 commit
  29. 20 Aug, 2007 1 commit
  30. 21 May, 2007 1 commit
  31. 16 May, 2007 1 commit
  32. 26 May, 2007 1 commit
    • Isaac Dupree's avatar
      parseInteger->parseUnsignedInteger to clarify meaning · 4a1aca10
      Isaac Dupree authored
      I decided against adding parseSignedInteger since octal
      and hex literals often have junk between the '-' and the
      digits, but, compare to Util.readRational which does handle
      signed numbers.  Also since Integers - mathematically and
      in Haskell - can be negative, normally.
      4a1aca10
  33. 10 May, 2007 3 commits
  34. 11 Oct, 2006 1 commit
    • Simon Marlow's avatar
      Module header tidyup, phase 1 · 49c98d14
      Simon Marlow authored
      This patch is a start on removing import lists and generally tidying
      up the top of each module.  In addition to removing import lists:
      
         - Change DATA.IOREF -> Data.IORef etc.
         - Change List -> Data.List etc.
         - Remove $Id$
         - Update copyrights
         - Re-order imports to put non-GHC imports last
         - Remove some unused and duplicate imports
      49c98d14
  35. 05 Oct, 2006 1 commit
  36. 29 Jun, 2006 1 commit
  37. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab