1. 22 Oct, 2009 1 commit
  2. 18 Oct, 2009 3 commits
  3. 03 Aug, 2009 1 commit
  4. 09 Jun, 2009 1 commit
    • Duncan Coutts's avatar
      Add PrimCall to the STG layer and update Core -> STG translation · cbbee4e8
      Duncan Coutts authored
      It adds a third case to StgOp which already hold StgPrimOp and StgFCallOp.
      The code generation for the new StgPrimCallOp case is almost exactly the
      same as for out-of-line primops. They now share the tailCallPrim function.
      In the Core -> STG translation we map foreign calls using the "prim"
      calling convention to the StgPrimCallOp case. This is because in Core we
      represent prim calls using the ForeignCall stuff. At the STG level however
      the prim calls are really much more like primops than foreign calls.
      cbbee4e8
  5. 23 May, 2009 1 commit
  6. 30 Mar, 2009 1 commit
  7. 23 Mar, 2009 1 commit
    • Bertram Felgenhauer's avatar
      update list of C math functions · f7ecb11b
      Bertram Felgenhauer authored
      Fix via C compilation of modules that import, say, log1p from math.h (#3117)
      
      The list is based on preprocessing Stg.h with glibc 2.6.1 headers, and
      cross-checked with the ISO C 99 standard (draft).
      f7ecb11b
  8. 06 Feb, 2009 1 commit
    • Ian Lynagh's avatar
      When generating C, don't pretend functions are data · 497302c4
      Ian Lynagh authored
      We used to generated things like:
          extern StgWordArray (newCAF) __attribute__((aligned (8)));
          ((void (*)(void *))(W_)&newCAF)((void *)R1.w);
      (which is to say, pretend that newCAF is some data, then cast it to a
      function and call it).
      This goes wrong on at least IA64, where:
          A function pointer on the ia64 does not point to the first byte of
          code. Intsead, it points to a structure that describes the function.
          The first quadword in the structure is the address of the first byte
          of code
      so we end up dereferencing function pointers one time too many, and
      segfaulting.
      497302c4
  9. 13 Oct, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      Big collection of patches for the new codegen branch. · e6243a81
      dias@eecs.harvard.edu authored
      o Fixed bug that emitted the copy-in code for closure entry
        in the wrong place -- at the initialization of the closure.
      o Refactored some of the closure entry code.
      o Added code to check that no LocalRegs are live-in to a procedure
         -- trip up some buggy programs earlier
      o Fixed environment bindings for thunks
         -- we weren't (re)binding the free variables in a thunk
      o Fixed a bug in proc-point splitting that dropped some updates
        to the entry block in a procedure.
      o Fixed improper calls to code that generates CmmLit's for strings
      o New invariant on cg_loc in CgIdInfo: the expression is always tagged
      o Code to load free vars on entry to a thunk was (wrongly) placed before
        the heap check.
      o Some of the StgCmm code was redundantly passing around Id's
        along with CgIdInfo's; no more.
      o Initialize the LocalReg's that point to a closure before allocating and
        initializing the closure itself -- otherwise, we have problems with
        recursive closure bindings
      o BlockEnv and BlockSet types are now abstract.
      o Update frames:
        - push arguments in Old call area
        - keep track of the return sp in the FCode monad
        - keep the return sp in every call, tail call, and return
            (because it might be different at different call sites,
             e.g. tail calls to the gc after a heap check are performed
                  before pushing the update frame)
        - set the sp appropriately on returns and tail calls
      o Reduce call, tail call, and return to a single LastCall node
      o Added slow entry code, using different calling conventions on entry and tail call
      o More fixes to the calling convention code.
        The tricky stuff is all about the closure environment: it must be passed in R1,
        but in non-closures, there is no such argument, so we can't treat all arguments
        the same way: the closure environment is special. Maybe the right step forward
        would be to define a different calling convention for closure arguments.
      o Let-no-escapes need to be emitted out-of-line -- otherwise, we drop code.
      o Respect RTS requirement of word alignment for pointers
        My stack allocation can pack sub-word values into a single word on the stack,
        but it wasn't requiring word-alignment for pointers. It does now,
        by word-aligning both pointer registers and call areas.
      o CmmLint was over-aggresively ruling out non-word-aligned memory references,
        which may be kosher now that we can spill small values into a single word.
      o Wrong label order on a conditional branch when compiling switches.
      o void args weren't dropped in many cases.
        To help prevent this kind of mistake, I defined a NonVoid wrapper,
        which I'm applying only to Id's for now, although there are probably
        other good candidates.
      o A little code refactoring: separate modules for procpoint analysis splitting, 
        stack layout, and building infotables.
      o Stack limit check: insert along with the heap limit check, using a symbolic
        constant (a special CmmLit), then replace it when the stack layout is known.
      o Removed last node: MidAddToContext 
      o Adding block id as a literal: means that the lowering of the calling conventions
        no longer has to produce labels early, which was inhibiting common-block elimination.
        Will also make it easier for the non-procpoint-splitting path.
      o Info tables: don't try to describe the update frame!
      o Over aggressive use of NonVoid!!!!
        Don't drop the non-void args before setting the type of the closure!!!
      o Sanity checking:
        Added a pass to stub dead dead slots on the stack
        (only ~10 lines with the dataflow framework)
      o More sanity checking:
        Check that incoming pointer arguments are non-stubbed.
        Note: these checks are still subject to dead-code removal, but they should
        still be quite helpful.
      o Better sanity checking: why stop at function arguments?
        Instead, in mkAssign, check that _any_ assignment to a pointer type is non-null
        -- the sooner the crash, the easier it is to debug.
        Still need to add the debugging flag to turn these checks on explicitly.
      o Fixed yet another calling convention bug.
        This time, the calls to the GC were wrong. I've added a new convention
        for GC calls and invoked it where appropriate.
        We should really straighten out the calling convention stuff:
          some of the code (and documentation) is spread across the compiler,
          and there's some magical use of the node register that should really
          be handled (not avoided) by calling conventions.
      o Switch bug: the arms in mkCmmLitSwitch weren't returning to a single join point.
      o Environment shadowing problem in Stg->Cmm:
        When a closure f is bound at the top-level, we should not bind f to the
        node register on entry to the closure.
        Why? Because if the body of f contains a let-bound closure g that refers
        to f, we want to make sure that it refers to the static closure for f.
        Normally, this would all be fine, because when we compile a closure,
        we rebind free variables in the environment. But f doesn't look like
        a free variable because it's a static value. So, the binding for f
        remains in the environment when we compile g, inconveniently referring
        to the wrong thing.
        Now, I bind the variable in the local environment only if the closure is not
        bound at the top level. It's still okay to make assumptions about the
        node holding the closure environment; we just won't find the binding
        in the environment, so code that names the closure will now directly
        get the label of the static closure, not the node register holding a
        pointer to the static closure.
      o Don't generate bogus Cmm code containing SRTs during the STG -> Cmm pass!
        The tables made reference to some labels that don't exist when we compute and
        generate the tables in the back end.
      o Safe foreign calls need some special treatment (at least until we have the integrated
        codegen). In particular:
        o they need info tables
        o they are not procpoints -- the successor had better be in the same procedure
        o we cannot (yet) implement the calling conventions early, which means we have
          to carry the calling-conv info all the way to the end
      o We weren't following the old convention when registering a module.
        Now, we use update frames to push any new modules that have to be registered
        and enter the youngest one on the stack.
        We also use the update frame machinery to specify that the return should pop
        the return address off the stack.
      o At each safe foreign call, an infotable must be at the bottom of the stack,
        and the TSO->sp must point to it.
      o More problems with void args in a direct call to a function:
        We were checking the args (minus voids) to check whether the call was saturated,
        which caused problems when the function really wasn't saturated because it
        took an extra void argument.
      o Forgot to distinguish integer != from floating != during Stg->Cmm
      o Updating slotEnv and areaMap to include safe foreign calls
        The dataflow analyses that produce the slotEnv and areaMap give
        results for each basic block, but we also need the results for
        a safe foreign call, which is a middle node.
        After running the dataflow analysis, we have another pass that
        updates the results to includ any safe foreign calls.
      o Added a static flag for the debugging technique that inserts
        instructions to stub dead slots on the stack and crashes when
        a stubbed value is loaded into a pointer-typed LocalReg.
      o C back end expects to see return continuations before their call sites.
        Sorted the flowgraphs appropriately after splitting.
      o PrimOp calling conventions are special -- unlimited registers, no stack
        Yet another calling convention...
      o More void value problems: if the RHS of a case arm is a void-typed variable,
        don't try to return it.
      o When calling some primOp, they may allocate memory; if so, we need to
        do a heap check when we return from the call.
      e6243a81
  10. 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
  11. 18 Nov, 2008 1 commit
    • Simon Marlow's avatar
      Add optional eager black-holing, with new flag -feager-blackholing · d600bf7a
      Simon Marlow authored
      Eager blackholing can improve parallel performance by reducing the
      chances that two threads perform the same computation.  However, it
      has a cost: one extra memory write per thunk entry.  
      
      To get the best results, any code which may be executed in parallel
      should be compiled with eager blackholing turned on.  But since
      there's a cost for sequential code, we make it optional and turn it on
      for the parallel package only.  It might be a good idea to compile
      applications (or modules) with parallel code in with
      -feager-blackholing.
      
      ToDo: document -feager-blackholing.
      d600bf7a
  12. 25 Jul, 2008 1 commit
  13. 11 Jul, 2008 1 commit
  14. 14 May, 2008 1 commit
    • Simon Marlow's avatar
      FIX #2276: foreign import stdcall "&foo" doesn't work · bca74f3e
      Simon Marlow authored
      This turned out not to be too hard, just a matter of figuring out the
      correct argument list size by peeking inside FunPtr's type argument,
      and in the C backend we have to emit an appropriate prototype for the label.
      bca74f3e
  15. 23 Apr, 2008 1 commit
  16. 12 Apr, 2008 1 commit
  17. 09 Apr, 2008 1 commit
  18. 02 Apr, 2008 1 commit
    • Simon Marlow's avatar
      Do not #include external header files when compiling via C · c245355e
      Simon Marlow authored
      This has several advantages:
      
       - -fvia-C is consistent with -fasm with respect to FFI declarations:
         both bind to the ABI, not the API.
      
       - foreign calls can now be inlined freely across module boundaries, since
         a header file is not required when compiling the call.
      
       - bootstrapping via C will be more reliable, because this difference
         in behavour between the two backends has been removed.
      
      There is one disadvantage:
      
       - we get no checking by the C compiler that the FFI declaration
         is correct.
      
      So now, the c-includes field in a .cabal file is always ignored by
      GHC, as are header files specified in an FFI declaration.  This was
      previously the case only for -fasm compilations, now it is also the
      case for -fvia-C too.
      c245355e
  19. 21 Sep, 2007 1 commit
  20. 06 Sep, 2007 1 commit
    • nr@eecs.harvard.edu's avatar
      massive changes to add a 'zipper' representation of C-- · 16a2f6a8
      nr@eecs.harvard.edu authored
      Changes too numerous to comment on, but here is some old history that
      I saved: 
      
      
      Wed Aug 15 11:07:13 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * type synonyms made consistent with new Cmm types
      
          M ./compiler/nativeGen/MachInstrs.hs -2 +2
      
      Mon Aug 20 19:22:14 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * pushing return info beyond cmm into codegen
      
          M ./compiler/codeGen/Bitmap.hs r3
          M ./compiler/codeGen/CgBindery.lhs r3
          M ./compiler/codeGen/CgCallConv.hs r3
          M ./compiler/codeGen/CgCase.lhs r3
          M ./compiler/codeGen/CgClosure.lhs r3
          M ./compiler/codeGen/CgCon.lhs r3
          M ./compiler/codeGen/CgExpr.lhs r3
          M ./compiler/codeGen/CgForeignCall.hs -6 +7 r3
          M ./compiler/codeGen/CgHeapery.lhs r3
          M ./compiler/codeGen/CgHpc.hs +1 r3
          M ./compiler/codeGen/CgInfoTbls.hs r3
          M ./compiler/codeGen/CgLetNoEscape.lhs r3
          M ./compiler/codeGen/CgMonad.lhs r3
          M ./compiler/codeGen/CgParallel.hs r3
          M ./compiler/codeGen/CgPrimOp.hs +3 r3
          M ./compiler/codeGen/CgProf.hs r3
          M ./compiler/codeGen/CgStackery.lhs r3
          M ./compiler/codeGen/CgTailCall.lhs r3
          M ./compiler/codeGen/CgTicky.hs r3
          M ./compiler/codeGen/CgUtils.hs -1 +1 r3
          M ./compiler/codeGen/ClosureInfo.lhs r3
          M ./compiler/codeGen/CodeGen.lhs r3
          M ./compiler/codeGen/SMRep.lhs r3
          M ./compiler/nativeGen/AsmCodeGen.lhs -2 +2 r1
          M ./compiler/nativeGen/MachCodeGen.hs -3 +3 r1
          M ./compiler/nativeGen/MachInstrs.hs r1
          M ./compiler/nativeGen/MachRegs.lhs r1
          M ./compiler/nativeGen/NCGMonad.hs r1
          M ./compiler/nativeGen/PositionIndependentCode.hs r1
          M ./compiler/nativeGen/PprMach.hs r1
          M ./compiler/nativeGen/RegAllocInfo.hs r1
          M ./compiler/nativeGen/RegisterAlloc.hs r1
      
      Mon Aug 20 20:54:41 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * put CmmReturnInfo into a CmmCall (and related types)
      
          M ./compiler/cmm/Cmm.hs -2 +1 r3
          M ./compiler/cmm/CmmBrokenBlock.hs -13 +12 r1
          M ./compiler/cmm/CmmCPS.hs -3 +3
          M ./compiler/cmm/CmmCPSGen.hs -8 +6 r1
          M ./compiler/cmm/CmmLint.hs -1 +1
          M ./compiler/cmm/CmmLive.hs -1 +1
          M ./compiler/cmm/CmmOpt.hs -3 +3
          M ./compiler/cmm/CmmParse.y -6 +6 r3
          M ./compiler/cmm/PprC.hs -3 +3
          M ./compiler/cmm/PprCmm.hs -7 +4 r2
          M ./compiler/codeGen/CgForeignCall.hs -7 +6 r2
          M ./compiler/codeGen/CgHpc.hs -1 r1
          M ./compiler/codeGen/CgPrimOp.hs -3 r1
          M ./compiler/codeGen/CgUtils.hs -1 +1 r1
          M ./compiler/nativeGen/AsmCodeGen.lhs -2 +2
          M ./compiler/nativeGen/MachCodeGen.hs -3 +3 r1
      
      Tue Aug 21 18:09:13 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * add call info in nativeGen
      
          M ./compiler/nativeGen/AsmCodeGen.lhs r1
          M ./compiler/nativeGen/MachInstrs.hs r1
          M ./compiler/nativeGen/MachRegs.lhs r1
          M ./compiler/nativeGen/NCGMonad.hs r1
          M ./compiler/nativeGen/PositionIndependentCode.hs r1
          M ./compiler/nativeGen/PprMach.hs r1
          M ./compiler/nativeGen/RegAllocInfo.hs r1
      
      Wed Aug 22 16:41:58 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * ListGraph is now a newtype, not a synonym
        The resultant bookkeepping is unenviable, but the change
        greatly simplifies our ability to make Cmm things propertly
        Outputable for both list-graph and zipper-graph representations.
      
          M ./compiler/cmm/Cmm.hs -5 +3
          M ./compiler/cmm/CmmCPS.hs -2 +2
          M ./compiler/cmm/CmmCPSGen.hs -1 +1
          M ./compiler/cmm/CmmContFlowOpt.hs -3 +3
          M ./compiler/cmm/CmmCvt.hs -2 +2
          M ./compiler/cmm/CmmInfo.hs -2 +3
          M ./compiler/cmm/CmmLint.hs -1 +1
          M ./compiler/cmm/CmmOpt.hs -2 +2
          M ./compiler/cmm/PprC.hs -1 +1
          M ./compiler/cmm/PprCmm.hs -5 +8
          M ./compiler/cmm/PprCmmZ.hs -7 +1
          M ./compiler/codeGen/CgMonad.lhs -1 +1
          M ./compiler/nativeGen/AsmCodeGen.lhs -15 +15
          M ./compiler/nativeGen/MachCodeGen.hs -2 +2
          M ./compiler/nativeGen/PositionIndependentCode.hs -6 +6
          M ./compiler/nativeGen/PprMach.hs -3 +2
          M ./compiler/nativeGen/RegAllocColor.hs +1
          M ./compiler/nativeGen/RegAllocLinear.hs -4 +5
          M ./compiler/nativeGen/RegCoalesce.hs -6 +6
          M ./compiler/nativeGen/RegLiveness.hs -12 +12
      
      Thu Aug 23 13:44:49 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * diagnostic assistance in case fromJust fails
      
          M ./compiler/nativeGen/MachCodeGen.hs -2 +5
      
      Thu Aug 23 14:07:28 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * give every block, even the first, a label
          With branch-chain elimination, the first block of a procedure
          might be the target of a branch.  This actually happens to 
          a dozen or more procedures in the run-time system.
      
          M ./compiler/nativeGen/PprMach.hs -8 +3
      
      Fri Aug 24 17:27:04 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * clean up the code in PprMach
      
          M ./compiler/nativeGen/PprMach.hs -16 +14
      
      Fri Aug 24 19:35:03 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * a bunch of impedance matching to get the compiler to build, plus 
         * the plus is diagnostics for unreachable code, which required
           moving a lot of prettyprinting code
      
          M ./compiler/cmm/Cmm.hs -7 +5
          M ./compiler/cmm/CmmCPSZ.hs -1 +1
          M ./compiler/cmm/CmmCvt.hs -8 +8
          M ./compiler/cmm/CmmParse.y -4 +3
          M ./compiler/cmm/MkZipCfg.hs -19 +9
          M ./compiler/cmm/PprCmmZ.hs -118 +4
          M ./compiler/cmm/ZipCfg.hs -1 +13
          M ./compiler/cmm/ZipCfgCmm.hs -10 +129
          M ./compiler/main/HscMain.lhs -4 +4
          M ./compiler/nativeGen/NCGMonad.hs -2 +2
          M ./compiler/nativeGen/RegAllocInfo.hs -3 +3
      
      Fri Aug 31 14:38:02 BST 2007  Norman Ramsey <nr@eecs.harvard.edu>
        * fix a warning about an import
      
          M ./compiler/nativeGen/RegAllocColor.hs -1 +1
      16a2f6a8
  21. 04 Sep, 2007 2 commits
  22. 03 Sep, 2007 1 commit
  23. 01 Sep, 2007 1 commit
  24. 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
  25. 18 Jul, 2007 2 commits
  26. 27 Jun, 2007 3 commits
  27. 28 Jun, 2007 1 commit
  28. 22 Jun, 2007 1 commit
  29. 28 Feb, 2007 1 commit
  30. 07 Feb, 2007 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Lightweight ticky-ticky profiling · 5ddee764
      chevalier@alum.wellesley.edu authored
      The following changes restore ticky-ticky profiling to functionality
      from its formerly bit-rotted state. Sort of. (It got bit-rotted as part
      of the switch to the C-- back-end.)
      
      The way that ticky-ticky is supposed to work is documented in Section 5.7
      of the GHC manual (though the manual doesn't mention that it hasn't worked
      since sometime around 6.0, alas). Changes from this are as follows (which
      I'll document on the wiki):
      
      * In the past, you had to build all of the libraries with way=t in order to
      use ticky-ticky, because it entailed a different closure layout. No longer.
      You still need to do make way=t in rts/ in order to build the ticky RTS,
      but you should now be able to mix ticky and non-ticky modules.
      
      * Some of the counters that worked in the past aren't implemented yet.
      I was originally just trying to get entry counts to work, so those should
      be correct. The list of counters was never documented in the first place,
      so I hope it's not too much of a disaster that some don't appear anymore.
      Someday, someone (perhaps me) should document all the counters and what 
      they do. For now, all of the counters are either accurate (or at least as
      accurate as they always were), zero, or missing from the ticky profiling
      report altogether.
      
      This hasn't been particularly well-tested, but these changes shouldn't
      affect anything except when compiling with -fticky-ticky (famous last
      words...)
      
      Implementation details:
      
      I got rid of StgTicky.h, which in the past had the macros and declarations 
      for all of the ticky counters. Now, those macros are defined in Cmm.h.
      StgTicky.h was still there for inclusion in C code. Now, any remaining C
      code simply cannot call the ticky macros -- or rather, they do call those
      macros, but from the perspective of C code, they're defined as no-ops. 
      (This shouldn't be too big a problem.)
      
      I added a new file TickyCounter.h that has all the declarations for ticky
      counters, as well as dummy macros for use in C code. Someday, these 
      declarations should really be automatically generated, since they need
      to be kept consistent with the macros defined in Cmm.h.
      
      Other changes include getting rid of the header that was getting added to
      closures before, and getting rid of various code having to do with eager
      blackholing and permanent indirections (the changes under compiler/ 
      and rts/Updates.*).
      5ddee764
  31. 22 Jan, 2007 1 commit
  32. 09 Dec, 2006 1 commit
  33. 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
  34. 24 Oct, 2006 1 commit
    • andy@galois.com's avatar
      Haskell Program Coverage · d5934bbb
      andy@galois.com authored
      This large checkin is the new ghc version of Haskell
      Program Coverage, an expression-level coverage tool for Haskell.
      
      Parts:
      
       - Hpc.[ch] - small runtime support for Hpc; reading/writing *.tix files.
       - Coverage.lhs - Annotates the HsSyn with coverage tickboxes.
        - New Note's in Core,
            - TickBox      -- ticked on entry to sub-expression
            - BinaryTickBox  -- ticked on exit to sub-expression, depending
      	       	     -- on the boolean result.
      
        - New Stg level TickBox (no BinaryTickBoxes, though) 
      
      You can run the coverage tool with -fhpc at compile time. 
      Main must be compiled with -fhpc. 
      				      
      d5934bbb