1. 12 Sep, 2007 1 commit
    • Clemens Fruhwirth's avatar
      Sign extension hack to work around PC64 relocation limitation for binutils <2.17 for x86_64. · b8a64b8e
      Clemens Fruhwirth authored
      binutils <2.17 can't generate PC64 relocations for x86_64. Hence we
      emit only 32 bit PC relative offsets, and artifically stick a zero in
      front of them to make them 64 bit (see PprMach.sh ppr_item in
      pprDataItem). This works as long as the offset is <32bit AND it's
      positive. This is not the case for offsets in jump tables, they are
      all negative. This hack sign extends them with a MOVSXL instruction
      into the dead index register, then adding the properly sign extended
      offset to the jump table base label giving the correct target address
      for the following jump.
      b8a64b8e
  2. 07 Sep, 2007 1 commit
    • nr@eecs.harvard.edu's avatar
      a good deal of salutory renaming · fd8d0411
      nr@eecs.harvard.edu authored
      I've renamed a number of type and data constructors within Cmm so that
      the names used in the compiler may more closely reflect the C--
      specification 2.1.  I've done a bit of other renaming as well.
      Highlights:
      
        CmmFormal and CmmActual now bear a CmmKind (which for now is a
                                                    MachHint as before)
        CmmFormals = [CmmFormal] and CmmActuals = [CmmActual]
        
        suitable changes have been made to both code and nonterminals in the
        Cmm parser (which is as yet untested)
      
        For reasons I don't understand, parts of the code generator use a
        sequence of 'formal parameters' with no C-- kinds.  For these we now
        have the types
          type CmmFormalWithoutKind   = LocalReg
          type CmmFormalsWithoutKinds = [CmmFormalWithoutKind]
      
        A great many appearances of (Tau, MachHint) have been simplified to
        the appropriate CmmFormal or CmmActual, though I'm sure there are
        more opportunities.
      
        Kind and its data constructors are now renamed to
           data GCKind = GCKindPtr | GCKindNonPtr 
        to avoid confusion with the Kind used in the type checker and with CmmKind.
      
      Finally, in a somewhat unrelated bit (and in honor of Simon PJ, who
      thought of the name), the Whalley/Davidson 'transaction limit' is now
      called 'OptimizationFuel' with the net effect that there are no longer
      two unrelated uses of the abbreviation 'tx'.
      
      fd8d0411
  3. 05 Sep, 2007 1 commit
    • nr@eecs.harvard.edu's avatar
      change of representation for GenCmm, GenCmmTop, CmmProc · 16dc208a
      nr@eecs.harvard.edu authored
      The type parameter to a C-- procedure now represents a control-flow
      graph, not a single instruction.  The newtype ListGraph preserves the 
      current representation while enabling other representations and a
      sensible way of prettyprinting.  Except for a few changes in the
      prettyprinter the new compiler binary should be bit-for-bit identical
      to the old.
      16dc208a
  4. 04 Sep, 2007 1 commit
  5. 03 Sep, 2007 1 commit
  6. 01 Sep, 2007 1 commit
  7. 20 Aug, 2007 1 commit
  8. 09 Aug, 2007 1 commit
  9. 31 Jul, 2007 1 commit
    • Clemens Fruhwirth's avatar
      Change the strategy to determine dynamic data access · 81b2276f
      Clemens Fruhwirth authored
      Instead of attaching the information whether a Label is going to be
      accessed dynamically or not (distinction between IdLabel/DynLabel and
      additional flags in ModuleInitLabel and PlainModuleInitLabel), we hand
      dflags through the CmmOpt monad and the NatM monad. Before calling
      labelDynamic in PositionIndependentCode, we extract thisPackage from
      dflags and supply the current package to labelDynamic, so it can take
      this information into account instead of extracting it from the labels
      itself. This simplifies a lot of code in codeGen that just hands
      through this_pkg.
      81b2276f
  10. 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
  11. 10 Jul, 2007 1 commit
    • andy@galois.com's avatar
      FIX rts build failure for powerPC build · 6103e1e2
      andy@galois.com authored
      The rts was failing with 
      
      ../compiler/ghc-inplace -H64m -Onot -fasm -optc-O2 -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint  -hisuf thr_p_hi -hcsuf thr_p_hc -osuf thr_p_o -optc-DTHREADED_RTS -prof -#include posix/Itimer.h  -c PrimOps.cmm -o PrimOps.thr_p_o
      ghc-6.7.20070709: panic! (the 'impossible' happened)
        (GHC version 6.7.20070709 for powerpc-apple-darwin):
              iselExpr64(powerpc) %MO_U_Conv_I32_I64(16 / 4 - 2)
      
      There was a special case for x86; so it has been transliterated to the PPC, and the output code looks plausable.
      6103e1e2
  12. 08 Jul, 2007 1 commit
  13. 05 Jul, 2007 1 commit
  14. 28 Jun, 2007 1 commit
  15. 27 Jun, 2007 4 commits
  16. 25 May, 2007 1 commit
    • Michael D. Adams's avatar
      Moved global register saving from the backend to codeGen · bd3a364d
      Michael D. Adams authored
      This frees the Cmm data type from keeping a list of live global registers
      in CmmCall which helps prepare for the CPS conversion phase.
      
      CPS conversion does its own liveness analysis and takes input that should
      not directly refer to parameter registers (e.g. R1, F5, D3, L2).  Since
      these are the only things which could occur in the live global register
      list, CPS conversion makes that field of the CmmCall constructor obsolite.
      
      Once the CPS conversion pass is fully implemented, global register saving
      will move from codeGen into the CPS pass.  Until then, this patch
      is worth scrutinizing and testing to ensure it doesn't cause any performance
      or correctness problems as the code passed to the backends by the CPS
      converting will look very similar to the code that this patch makes codeGen
      pass to the backend.
      bd3a364d
  17. 26 Jun, 2007 1 commit
  18. 13 Jun, 2007 2 commits
  19. 18 May, 2007 1 commit
  20. 03 May, 2007 1 commit
  21. 01 Mar, 2007 3 commits
  22. 19 Jan, 2007 1 commit
  23. 11 Dec, 2006 2 commits
  24. 07 Dec, 2006 1 commit
    • wolfgang.thaller@gmx.net's avatar
      x86_64: support PIC and therefore, Mac OS X in the NCG · 28c556a5
      wolfgang.thaller@gmx.net authored
      Supporting x86_64-apple-darwin in the NCG basically boils down to supporting
      position-independent code in the NCG.
      PIC code works almost exactly the same as on x86_64-linux, while position-dependent
      code is not supported at all.
      This patch implements -fPIC for x86_64-linux, too, but that is untested.
      
      28c556a5
  25. 29 Nov, 2006 1 commit
  26. 24 Nov, 2006 1 commit
  27. 11 Oct, 2006 1 commit
  28. 10 Sep, 2006 1 commit
  29. 29 Jun, 2006 1 commit
  30. 20 Jun, 2006 1 commit
  31. 06 Jun, 2006 1 commit
  32. 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
  33. 25 Feb, 2006 1 commit
    • wolfgang.thaller@gmx.net's avatar
      NCG: Handle loops in register allocator · 34f992d3
      wolfgang.thaller@gmx.net authored
      Fill in the missing parts in the register allocator so that it can
      handle loops.
      
      *) The register allocator now runs in the UniqSuppy monad, as it needs
         to be able to generate unique labels for fixup code blocks.
      
      *) A few functions have been added to RegAllocInfo:
      	mkRegRegMoveInstr -- generates a good old move instruction
      	mkBranchInstr     -- used to be MachCodeGen.genBranch
      	patchJump         -- Change the destination of a jump
      
      *) The register allocator now makes sure that only one spill slot is used
         for each temporary, even if it is spilled and reloaded several times.
         This obviates the need for memory-to-memory moves in fixup code.
      
      LIMITATIONS:
      
      *) The case where the fixup code needs to cyclically permute a group of
         registers is currently unhandled. This will need more work once we come
         accross code where this actually happens.
      
      *) Register allocation for code with loop is probably very inefficient
         (both at compile-time and at run-time).
      
      *) We still cannot compile the RTS via NCG, for various other reasons.
      34f992d3