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, and can be resumed by a project maintainer.
Last successful update .
  1. 17 May, 2016 1 commit
    • Erik de Castro Lopo's avatar
      rts: More const correct-ness fixes · 33c029dd
      Erik de Castro Lopo authored
      In addition to more const-correctness fixes this patch fixes an
      infelicity of the previous const-correctness patch (995cf0f3) which
      left `UNTAG_CLOSURE` taking a `const StgClosure` pointer parameter
      but returning a non-const pointer. Here we restore the original type
      signature of `UNTAG_CLOSURE` and add a new function
      `UNTAG_CONST_CLOSURE` which takes and returns a const `StgClosure`
      pointer and uses that wherever possible.
      
      Test Plan: Validate on Linux, OS X and Windows
      
      Reviewers: Phyx, hsyl20, bgamari, austin, simonmar, trofi
      
      Reviewed By: simonmar, trofi
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2231
      33c029dd
  2. 29 Apr, 2016 1 commit
  3. 18 Apr, 2016 1 commit
  4. 07 Nov, 2015 1 commit
    • Simon Marlow's avatar
      Make GHCi & TH work when the compiler is built with -prof · ce1f1607
      Simon Marlow authored
      Summary:
      Amazingly, there were zero changes to the byte code generator and very
      few changes to the interpreter - mainly because we've used good
      abstractions that hide the differences between profiling and
      non-profiling.  So that bit was pleasantly straightforward, but there
      were a pile of other wibbles to get the whole test suite through.
      
      Note that a compiler built with -prof is now like one built with
      -dynamic, in that to use TH you have to build the code the same way.
      For dynamic, we automatically enable -dynamic-too when TH is required,
      but we don't have anything equivalent for profiling, so you have to
      explicitly use -prof when building code that uses TH with a profiled
      compiler.  For this reason Cabal won't work with TH.  We don't expect
      to ship a profiled compiler, so I think that's OK.
      
      Test Plan: validate with GhcProfiled=YES in validate.mk
      
      Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1407
      
      GHC Trac Issues: #4837, #545
      ce1f1607
  5. 20 Aug, 2014 1 commit
  6. 14 Mar, 2012 1 commit
  7. 27 Feb, 2012 1 commit
  8. 22 Nov, 2011 1 commit
  9. 25 Aug, 2011 1 commit
  10. 13 Sep, 2010 1 commit
  11. 03 Feb, 2010 1 commit
  12. 19 Aug, 2009 1 commit
  13. 02 Aug, 2009 1 commit
    • Simon Marlow's avatar
      RTS tidyup sweep, first phase · a2a67cd5
      Simon Marlow authored
      The first phase of this tidyup is focussed on the header files, and in
      particular making sure we are exposinng publicly exactly what we need
      to, and no more.
      
       - Rts.h now includes everything that the RTS exposes publicly,
         rather than a random subset of it.
      
       - Most of the public header files have moved into subdirectories, and
         many of them have been renamed.  But clients should not need to
         include any of the other headers directly, just #include the main
         public headers: Rts.h, HsFFI.h, RtsAPI.h.
      
       - All the headers needed for via-C compilation have moved into the
         stg subdirectory, which is self-contained.  Most of the headers for
         the rest of the RTS APIs have moved into the rts subdirectory.
      
       - I left MachDeps.h where it is, because it is so widely used in
         Haskell code.
       
       - I left a deprecated stub for RtsFlags.h in place.  The flag
         structures are now exposed by Rts.h.
      
       - Various internal APIs are no longer exposed by public header files.
      
       - Various bits of dead code and declarations have been removed
      
       - More gcc warnings are turned on, and the RTS code is more
         warning-clean.
      
       - More source files #include "PosixSource.h", and hence only use
         standard POSIX (1003.1c-1995) interfaces.
      
      There is a lot more tidying up still to do, this is just the first
      pass.  I also intend to standardise the names for external RTS APIs
      (e.g use the rts_ prefix consistently), and declare the internal APIs
      as hidden for shared libraries.
      a2a67cd5
  14. 02 Jun, 2009 1 commit
  15. 27 Jul, 2007 1 commit
    • Simon Marlow's avatar
      Pointer Tagging · 6015a94f
      Simon Marlow authored
        
      This patch implements pointer tagging as per our ICFP'07 paper "Faster
      laziness using dynamic pointer tagging".  It improves performance by
      10-15% for most workloads, including GHC itself.
      
      The original patches were by Alexey Rodriguez Yakushev
      <mrchebas@gmail.com>, with additions and improvements by me.  I've
      re-recorded the development as a single patch.
      
      The basic idea is this: we use the low 2 bits of a pointer to a heap
      object (3 bits on a 64-bit architecture) to encode some information
      about the object pointed to.  For a constructor, we encode the "tag"
      of the constructor (e.g. True vs. False), for a function closure its
      arity.  This enables some decisions to be made without dereferencing
      the pointer, which speeds up some common operations.  In particular it
      enables us to avoid costly indirect jumps in many cases.
      
      More information in the commentary:
      
      http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging
      6015a94f
  16. 13 Jun, 2007 1 commit
    • Simon Marlow's avatar
      FIX #1418 (partially) · 23e5985c
      Simon Marlow authored
      When the con_desc field of an info table was made into a relative
      reference, this had the side effect of making the profiling fields
      (closure_desc and closure_type) also relative, but only when compiling
      via C, and the heap profiler was still treating them as absolute,
      leading to crashes when profiling with -hd or -hy.
      
      This patch fixes up the story to be consistent: these fields really
      should be relative (otherwise we couldn't make shared versions of the
      profiling libraries), so I've made them relative and fixed up the RTS
      to know about this.
      23e5985c
  17. 10 May, 2007 1 commit
  18. 27 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Basic heap profile support without -prof · cbeb99ef
      Simon Marlow authored
      Now that constructor info tables contain the name of the constructor,
      we can generate useful heap profiles without requiring the whole
      program and libraries to be compiled with -prof.  So now, "+RTS -hT"
      generates a heap profile for any program, dividing the profile by
      constructor.  It wouldn't be hard to add support for grouping
      constructors by module, or to restrict the profile to certain
      constructors/modules/packages.
      
      This means that for the first time we can get heap profiles for GHCi,
      which was previously impossible because the byte-code
      interpreter and linker don't work with -prof.
      cbeb99ef
  19. 17 Apr, 2007 1 commit
  20. 28 Feb, 2007 1 commit
  21. 20 Feb, 2007 1 commit
    • bjpop@csse.unimelb.edu.au's avatar
      Constructor names in info tables · 7d6dffe5
      bjpop@csse.unimelb.edu.au authored
      This patch adds data constructor names into their info tables. 
      This is useful in the ghci debugger. It replaces the old scheme which
      was based on tracking data con names in the linker. 
      7d6dffe5
  22. 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
  23. 05 Apr, 2005 2 commits
    • simonmar's avatar
      [project @ 2005-04-05 21:24:53 by simonmar] · 060a1134
      simonmar authored
      wibble to fix the unreg way
      060a1134
    • simonmar's avatar
      [project @ 2005-04-05 09:38:00 by simonmar] · 3f4fd743
      simonmar authored
      Main x86_64 hacking: we have a problem on this arch where binutils
      can't generate 64-bit relative relocations (R_X86_64_PC64), which many
      of our info-table fields are.  So far we've been hacking around it by
      putting everything in the text section, but I've decided to adopt
      another approach: we'll use explicit 32-bit offset fields on this
      platform instead.  This is safe in the default "small" memory model
      where all symbols are guaranteed to be in the lower 2Gb of the address
      space.
      
      NCG changes coming; mangler changes are probably required too.
      3f4fd743
  24. 27 Mar, 2005 1 commit
    • panne's avatar
      [project @ 2005-03-27 13:41:13 by panne] · 03dc2dd3
      panne authored
      * Some preprocessors don't like the C99/C++ '//' comments after a
        directive, so use '/* */' instead. For consistency, a lot of '//' in
        the include files were converted, too.
      
      * UnDOSified libraries/base/cbits/runProcess.c.
      
      * My favourite sport: Killed $Id$s.
      03dc2dd3
  25. 08 Nov, 2004 1 commit
  26. 07 Oct, 2004 1 commit
    • wolfgang's avatar
      [project @ 2004-10-07 15:54:03 by wolfgang] · b4d045ae
      wolfgang authored
      Position Independent Code and Dynamic Linking Support, Part 1
      
      This commit allows generation of position independent code (PIC) that fully supports dynamic linking on Mac OS X and PowerPC Linux.
      Other platforms are not yet supported, and there is no support for actually linking or using dynamic libraries - so if you use the -fPIC or -dynamic code generation flags, you have to type your (platform-specific) linker command lines yourself.
      
      
      nativeGen/PositionIndependentCode.hs:
      New file. Look here for some more comments on how this works.
      
      cmm/CLabel.hs:
      Add support for DynamicLinkerLabels and PIC base labels - for use inside the NCG.
      needsCDecl: Case alternative labels now need C decls, see the codeGen/CgInfoTbls.hs below for details
      
      cmm/Cmm.hs:
      Add CmmPicBaseReg (used in NCG),
      and CmmLabelDiffOff (used in NCG and for offsets in info tables)
      
      cmm/CmmParse.y:
      support offsets in info tables
      
      cmm/PprC.hs:
      support CmmLabelDiffOff
      Case alternative labels now need C decls (see the codeGen/CgInfoTbls.hs for details), so we need to pprDataExterns for info tables.
      
      cmm/PprCmm.hs:
      support CmmLabelDiffOff
      
      codeGen/CgInfoTbls.hs:
      no longer store absolute addresses in info tables, instead, we store offsets.
      Also, for vectored return points, emit the alternatives _after_ the vector table. This is to work around a limitation in Apple's as, which refuses to handle label differences where one label is at the end of a section. Emitting alternatives after vector info tables makes sure this never happens in GHC generated code. Case alternatives now require prototypes in hc code, though (see changes in PprC.hs, CLabel.hs).
      
      main/CmdLineOpts.lhs:
      Add a new option, -fPIC.
      
      main/DriverFlags.hs:
      Pass the correct options for PIC to gcc, depending on the platform. Only for powerpc for now.
      
      nativeGen/AsmCodeGen.hs:
      Many changes...
      Mac OS X-specific management of import stubs is no longer, it's now part of a general mechanism to handle such things for all platforms that need it (Darwin [both ppc and x86], Linux on ppc, and some platforms we don't support).
      Move cmmToCmm into its own monad which can accumulate a list of imported symbols. Make it call cmmMakeDynamicReference at the right places.
      
      nativeGen/MachCodeGen.hs:
      nativeGen/MachInstrs.hs:
      nativeGen/MachRegs.lhs:
      nativeGen/PprMach.hs:
      nativeGen/RegAllocInfo.hs:
      Too many changes to enumerate here, PowerPC specific.
      
      nativeGen/NCGMonad.hs:
      NatM still tracks imported symbols, as more labels can be created during code generation (float literals, jump tables; on some platforms all data access has to go through the dynamic linking mechanism).
      
      driver/mangler/ghc-asm.lprl:
      Mangle absolute addresses in info tables to offsets.
      Correctly pass through GCC-generated PIC for Mac OS X and powerpc linux.
      
      includes/Cmm.h:
      includes/InfoTables.h:
      includes/Storage.h:
      includes/mkDerivedConstants.c:
      rts/GC.c:
      rts/GCCompact.c:
      rts/HeapStackCheck.cmm:
      rts/Printer.c:
      rts/RetainerProfile.c:
      rts/Sanity.c:
      Adapt to the fact that info tables now contain offsets.
      
      rts/Linker.c:
      Mac-specific: change machoInitSymbolsWithoutUnderscore to support PIC.
      b4d045ae
  27. 13 Aug, 2004 1 commit
  28. 14 Nov, 2003 2 commits
  29. 12 Nov, 2003 1 commit
    • sof's avatar
      [project @ 2003-11-12 17:27:00 by sof] · a814590c
      sof authored
      Tidy up a couple of unportable coding issues:
      
      - conditionally use empty structs.
      - use GNU attributes only if supported.
      - 'long long' usage
      - use of 'inline' in declarations and definitions.
      
      Upshot of these changes is that MSVC is now capable of compiling
      the non-.hc portions of the RTS.
      a814590c
  30. 14 May, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-05-14 09:13:52 by simonmar] · 7a236a56
      simonmar authored
      Change the way SRTs are represented:
      
      Previously, the SRT associated with a function or thunk would be a
      sub-list of the enclosing top-level function's SRT.  But this approach
      can lead to lots of duplication: if a CAF is referenced in several
      different thunks, then it may appear several times in the SRT.
      Let-no-escapes compound the problem, because the occurrence of a
      let-no-escape-bound variable would expand to all the CAFs referred to
      by the let-no-escape.
      
      The new way is to describe the SRT associated with a function or thunk
      as a (pointer+offset,bitmap) pair, where the pointer+offset points
      into some SRT table (the enclosing function's SRT), and the bitmap
      indicates which entries in this table are "live" for this closure.
      The bitmap is stored in the 16 bits previously used for the length
      field, but this rarely overflows.  When it does overflow, we store the
      bitmap externally in a new "SRT descriptor".
      
      Now the enclosing SRT can be a set, hence eliminating the duplicates.
      
      Also, we now have one SRT per top-level function in a recursive group,
      where previously we used to have one SRT for the whole group.  This
      helps keep the size of SRTs down.
      
      Bottom line: very little difference most of the time.  GHC itself got
      slightly smaller.  One bad case of a module in GHC which had a huge
      SRT has gone away.
      
      While I was in the area:
      
        - Several parts of the back-end require bitmaps.  Functions for
          creating bitmaps are now centralised in the Bitmap module.
      
        - We were trying to be independent of word-size in a couple of
          places in the back end, but we've now abandoned that strategy so I
          simplified things a bit.
      7a236a56
  31. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar authored
      Merge the eval-apply-branch on to the HEAD
      ------------------------------------------
      
      This is a change to GHC's evaluation model in order to ultimately make
      GHC more portable and to reduce complexity in some areas.
      
      At some point we'll update the commentary to describe the new state of
      the RTS.  Pending that, the highlights of this change are:
      
        - No more Su.  The Su register is gone, update frames are one
          word smaller.
      
        - Slow-entry points and arg checks are gone.  Unknown function calls
          are handled by automatically-generated RTS entry points (AutoApply.hc,
          generated by the program in utils/genapply).
      
        - The stack layout is stricter: there are no "pending arguments" on
          the stack any more, the stack is always strictly a sequence of
          stack frames.
      
          This means that there's no need for LOOKS_LIKE_GHC_INFO() or
          LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
          how to find the boundary between the text and data segments (BIG WIN!).
      
        - A couple of nasty hacks in the mangler caused by the neet to
          identify closure ptrs vs. info tables have gone away.
      
        - Info tables are a bit more complicated.  See InfoTables.h for the
          details.
      
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
          fixed.
      
        - Binary sizes are reduced by about 7% on x86.  Performance is roughly
          similar, some programs get faster while some get slower.  I've seen
          GHCi perform worse on some examples, but haven't investigated
          further yet (GHCi performance *should* be about the same or better
          in theory).
      
        - Internally the code generator is rather better organised.  I've moved
          info-table generation from the NCG into the main codeGen where it is
          shared with the C back-end; info tables are now emitted as arrays
          of words in both back-ends.  The NCG is one step closer to being able
          to support profiling.
      
      This has all been fairly thoroughly tested, but no doubt I've messed
      up the commit in some way.
      0bffc410
  32. 14 May, 2002 1 commit
  33. 01 May, 2002 1 commit
  34. 29 Jan, 2002 1 commit
  35. 18 Dec, 2001 1 commit
    • sebc's avatar
      [project @ 2001-12-18 19:42:41 by sebc] · 6ed4dbcc
      sebc authored
      THIS CHANGE AFFECTS ALL OBJECT FILES.
      Please say "make clean"
      
      Move the entry code pointer to the start of info tables, according
      to Plan C in ghc/rts/Storage.h
      6ed4dbcc
  36. 03 Oct, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-10-03 13:57:42 by simonmar] · b4623557
      simonmar authored
      Tidy up ghc/includes/Constants and related things.
      
      Now all the constants that the compiler needs to know, such as header
      size, update frame size, info table size and so on are generated
      automatically into a header file, DeriviedConstants.h, by a small C
      program in the same way as NativeDefs.h.  The C code in the RTS is
      expected to use sizeof() directly (it already does).
      
      Also tidied up the constants in MachDeps.h - all the constants
      representing the sizes of various types are named SIZEOF_<foo>, to
      match the constants defined in config.h.  PrelStorable.lhs now doesn't
      contain any special knowledge about GHC's conventions as regards the
      size of certain types, this is all in MachDeps.h.
      b4623557
  37. 29 Aug, 2001 1 commit
    • qrczak's avatar
      [project @ 2001-08-29 17:24:25 by qrczak] · aa84d93a
      qrczak authored
      Remove annoying warnings about using a deprecated extension
      when compiling via gcc-3.0.
      
      #if __GNUC__ >= 3
      /* Assume that a flexible array member at the end of a struct
       * can be defined thus: T arr[]; */
      #define FLEXIBLE_ARRAY
      #else
      /* Assume that it must be defined thus: T arr[0]; */
      #define FLEXIBLE_ARRAY 0
      #endif
      
      A test program (hsking) compiled fine with gcc-3.0!
      aa84d93a
  38. 22 Mar, 2001 1 commit
    • hwloidl's avatar
      [project @ 2001-03-22 03:51:08 by hwloidl] · 20fc2f0c
      hwloidl authored
      -*- outline -*-
      Time-stamp: <Thu Mar 22 2001 03:50:16 Stardate: [-30]6365.79 hwloidl>
      
      This commit covers changes in GHC to get GUM (way=mp) and GUM/GdH (way=md)
      working. It is a merge of my working version of GUM, based on GHC 4.06,
      with GHC 4.11. Almost all changes are in the RTS (see below).
      
      GUM is reasonably stable, we used the 4.06 version in large-ish programs for
      recent papers. Couple of things I want to change, but nothing urgent.
      GUM/GdH has just been merged and needs more testing. Hope to do that in the
      next weeks. It works in our working build but needs tweaking to run.
      GranSim doesn't work yet (*sigh*). Most of the code should be in, but needs
      more debugging.
      
      ToDo: I still want to make the following minor modifications before the release
      - Better wrapper skript for parallel execution [ghc/compiler/main]
      - Update parallel docu: started on it but it's minimal [ghc/docs/users_guide]
      - Clean up [nofib/parallel]: it's a real mess right now (*sigh*)
      - Update visualisation tools (minor things only IIRC) [ghc/utils/parallel]
      - Add a Klingon-English glossary
      
      * RTS:
      
      Almost all changes are restricted to ghc/rts/parallel and should not
      interfere with the rest. I only comment on changes outside the parallel
      dir:
      
      - Several changes in Schedule.c (scheduling loop; createThreads etc);
        should only affect parallel code
      - Added ghc/rts/hooks/ShutdownEachPEHook.c
      - ghc/rts/Linker.[ch]: GUM doesn't know about Stable Names (ifdefs)!!
      - StgMiscClosures.h: END_TSO_QUEUE etc now defined here (from StgMiscClosures.hc)
                           END_ECAF_LIST was missing a leading stg_
      - SchedAPI.h: taskStart now defined in here; it's only a wrapper around
                    scheduleThread now, but might use some init, shutdown later
      - RtsAPI.h: I have nuked the def of rts_evalNothing
      
      * Compiler:
      
      - ghc/compiler/main/DriverState.hs
        added PVM-ish flags to the parallel way
        added new ways for parallel ticky profiling and distributed exec
      
      - ghc/compiler/main/DriverPipeline.hs
        added a fct run_phase_MoveBinary which is called with way=mp after linking;
        it moves the bin file into a PVM dir and produces a wrapper script for
        parallel execution
        maybe cleaner to add a MoveBinary phase in DriverPhases.hs but this way
        it's less intrusive and MoveBinary makes probably only sense for mp anyway
      
      * Nofib:
      
      - nofib/spectral/Makefile, nofib/real/Makefile, ghc/tests/programs/Makefile:
        modified to skip some tests if HWL_NOFIB_HACK is set; only tmp to record
        which test prgs cause problems in my working build right now
      20fc2f0c