1. 29 May, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Implement -XMonoLocalBinds: a radical new flag · 903831d5
      simonpj@microsoft.com authored
      The new flag -XMonoLocalBinds tells GHC not to generalise nested
      bindings in let or where clauses, unless there is a type signature,
      in which case we use it.  
      
      I'm thinking about whether this might actually be a good direction for
      Haskell go to in, although it seems pretty radical.  Anyway, the flag
      is easy to implement (look at how few lines change), and having it
      will allow us to experiement with and without.
      
      Just for the record, below are the changes required in the boot 
      libraries -- ie the places where.  Not quite as minimal as I'd hoped,
      but the changes fall into a few standard patterns, and most represent
      (in my opinion) sytlistic improvements.  I will not push these patches,
      however.
      
      == running darcs what -s --repodir libraries/base
      M ./Control/Arrow.hs -2 +4
      M ./Data/Data.hs -7 +22
      M ./System/IO/Error.hs +1
      M ./Text/ParserCombinators/ReadP.hs +1
      == running darcs what -s --repodir libraries/bytestring
      M ./Data/ByteString/Char8.hs -1 +2
      M ./Data/ByteString/Unsafe.hs +1
      == running darcs what -s --repodir libraries/Cabal
      M ./Distribution/PackageDescription.hs -2 +6
      M ./Distribution/PackageDescription/Check.hs +3
      M ./Distribution/PackageDescription/Configuration.hs -1 +3
      M ./Distribution/ParseUtils.hs -2 +4
      M ./Distribution/Simple/Command.hs -1 +4
      M ./Distribution/Simple/Setup.hs -12 +24
      M ./Distribution/Simple/UserHooks.hs -1 +5
      == running darcs what -s --repodir libraries/containers
      M ./Data/IntMap.hs -2 +2
      == running darcs what -s --repodir libraries/dph
      M ./dph-base/Data/Array/Parallel/Arr/BBArr.hs -1 +3
      M ./dph-base/Data/Array/Parallel/Arr/BUArr.hs -2 +4
      M ./dph-prim-par/Data/Array/Parallel/Unlifted/Distributed/Arrays.hs -6 +10
      M ./dph-prim-par/Data/Array/Parallel/Unlifted/Distributed/Combinators.hs -3 +6
      M ./dph-prim-seq/Data/Array/Parallel/Unlifted/Sequential/Flat/Permute.hs -2 +4
      == running darcs what -s --repodir libraries/syb
      M ./Data/Generics/Twins.hs -5 +18
      
      903831d5
  2. 28 May, 2009 3 commits
  3. 18 May, 2009 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      Split Reg into vreg/hreg and add register pairs · f9288086
      Ben.Lippmeier@anu.edu.au authored
       * The old Reg type is now split into VirtualReg and RealReg.
       * For the graph coloring allocator, the type of the register graph
         is now (Graph VirtualReg RegClass RealReg), which shows that it colors
         in nodes representing virtual regs with colors representing real regs.
         (as was intended)  
       * RealReg contains two contructors, RealRegSingle and RealRegPair,
         where RealRegPair is used to represent a SPARC double reg 
         constructed from two single precision FP regs. 
       * On SPARC we can now allocate double regs into an arbitrary register
         pair, instead of reserving some reg ranges to only hold float/double values. 
      f9288086
  4. 20 May, 2009 1 commit
  5. 19 May, 2009 2 commits
    • Duncan Coutts's avatar
      When linking a shared library with --make, always do the link step · 8aaa9ef4
      Duncan Coutts authored
      Without -shared, the default target is a binary and in that case
      it makes sense for --make to not try and link a binary when there
      is no Main module. But for a shared library the user already has
      to specify -shared and there's no reason a shared lib should
      contain any Main module or main function.
      8aaa9ef4
    • Duncan Coutts's avatar
      Make -dynload sysdep mean to embed rpaths in shared libs as well as binaries · 527f52a7
      Duncan Coutts authored
      Previously it only did it for binaries. This was presumably on the
      theory that the binary could specify the rpath for all the libs.
      However when it is the shared lib that is the final product (ie to
      link into a bigger project) then we need the rpaths for the shared
      lib to be self-contianed.
      527f52a7
  6. 17 May, 2009 1 commit
  7. 15 May, 2009 2 commits
    • Duncan Coutts's avatar
      Set the soname when creating a shared lib · 6efacfe8
      Duncan Coutts authored
      It's still possible to override it, just use -optl-Wl,-soname, eg:
      ghc -shared -dynamic foo.o -o libfoo.so -optl-Wl,-soname,libbar.so
      6efacfe8
    • Duncan Coutts's avatar
      Keep C main separate from rts lib and link it in for standalone progs · fa00cc50
      Duncan Coutts authored
      Previously the object code for the C main function lived in the rts
      lib, however this is a problem when the rts is built as a shared lib.
      With Windows DLLs it always causes problems while on ELF systems it's a
      problem when the user decides to use their own C main function rather
      than a Haskell Main.main. So instead we now put main in it's own tiny
      little static lib libHSrtsmain.a which we install next to the rts libs.
      Whenever ghc links a program (without -no-hs-main) then it also links
      in -lHSrtsmain. For consistency we always do it this way now rather
      than trying to do it differently for static vs shared libraries.
      fa00cc50
  8. 14 May, 2009 1 commit
    • Duncan Coutts's avatar
      Remove old Windows-only implementation of keeping main outside the rts · 3d411991
      Duncan Coutts authored
      We now do it for all ways and for all platforms. This was a Windows-only
      version that only kept a separate Main.dyn_o for the dynamic linking case.
      It had to do that because Windows DLLs are stricter about unresolved symbols
      where as for ELF platforms we only run into the problem when we're not using
      a Haskell main function.
      3d411991
  9. 20 May, 2009 5 commits
  10. 19 May, 2009 1 commit
  11. 01 May, 2009 1 commit
    • Duncan Coutts's avatar
      Make ghc -dynamic imply -fPIC for C code · 431e40e1
      Duncan Coutts authored
      As is already the case for ghc -fPIC. This is needed because ghc -dynamic
      means to generate code that is capable of being linked to Haskell shared
      libs and for C code the equivalent is -fPIC. Normally C code does not need
      -fPIC merely to link to shared libs however Haskell shared libs do not
      follow common conventions. In particular the static data cannot be
      referenced statically because it cannot be copied by the static linker.
      The linker cannot copy them because we do not specify a .size for the
      _closure entries (in the .data section) though in principle we could.
      431e40e1
  12. 13 May, 2009 1 commit
  13. 22 Apr, 2009 1 commit
  14. 28 Apr, 2009 1 commit
    • Ian Lynagh's avatar
      Fix error handling · e213baf0
      Ian Lynagh authored
      After the fix to #2500, we could get "Failing due to -Werror." but no
      warnings printed. Now we don't fail in that case.
      e213baf0
  15. 26 Apr, 2009 2 commits
  16. 24 Apr, 2009 1 commit
  17. 21 Apr, 2009 3 commits
    • Simon Marlow's avatar
      FIX #2682: banish silly cases of the "module Foo is not loaded" error · ef03a76a
      Simon Marlow authored
      In GHCi if you say 'import Foo' meaning to load a package module Foo,
      and Foo.hs is found on the search path, then GHCi replies "module Foo
      is not loaded", because it knows Foo refers to the source file rather
      than the package module, and you haven't loaded that module with
      :load.
      
      This is consistent with the usual module-finding semantics.  However,
      it isn't particularly useful.  And it leads to silly problems like not
      being able to start GHCi when you happen to be sitting in
      libraries/base, because GHCi thinks the Prelude hasn't been loaded.
      
      So now I've made a slight change to the way that 'import M' works: if
      M is loaded, then it refers to the loaded module, otherwise it looks
      for a package module M.  This does what the reporter of #2682 wanted,
      and since it turns an error condition into meaningful behaviour it
      can't break anything.  
      
      The only undesirable consequence is that 'import M' might refer to a
      different M than ':load M'.  Hopefully that won't lead to confusion.
      ef03a76a
    • Simon Marlow's avatar
      FIX #2500: Don't log warnings in getHeader · a70a6e39
      Simon Marlow authored
      a70a6e39
    • Simon Marlow's avatar
  18. 20 Apr, 2009 1 commit
    • Simon Marlow's avatar
      FIX #2845: Allow breakpoints on expressions with unlifted type · 709c9ce0
      Simon Marlow authored
      It turns out we can easily support breakpoints on expressions with
      unlifted types, by translating 
      
        case tick# of _ -> e
      
      into
      
        let f = \s . case tick# of _ -> e 
        in  f realWorld#
      
      instead of just a plain let-binding.  This is the same trick that GHC
      uses for abstracting join points of unlifted type.
      
      In #2845, GHC has eta-expanded the tick expression, changing the
      result type from IO a to (# State#, a #), which was the reason the
      tick was suddenly being ignored.  By supporting ticks on unlifted
      expressions we can make it work again, although some confusion might
      arise because _result will no longer be available (it now has
      unboxed-tuple type, so we can't bind it in the environment).  The
      underlying problem here is that GHC does transformations like
      eta-expanding the tick expressions, and there's nothing we can do to
      prevent that.
      709c9ce0
  19. 09 Apr, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3155: better error message when -XRankNTypes is omitted · 6c06fdc7
      simonpj@microsoft.com authored
      This patch sligtly re-adjusts the way in which the syntax of types 
      is handled:
      
       * In the lexer, '.' and '*' are always accepted in types
         (previously it was conditional).  This things can't mean
         anything else in H98, which is the only reason for doing things
         conditionally in the lexer.
      
       * As a result '.' in types is never treated as an operator.
         Instead, lacking a 'forall' keyword, it turns into a plain parse error.
      
       * Test for -XKindSignatures in the renamer when processing
           a) type variable bindings
           b) types with sigs (ty :: kind-sig)
      
       * Make -XKindSignatures be implied by -XTypeFamilies 
         Previously this was buried in the conditonal lexing of '*'
      6c06fdc7
  20. 03 Apr, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Adjust inlining heursitics · b71760aa
      simonpj@microsoft.com authored
      This patch is the result of a long series of nofib-based experiments
      to improve GHC's inlining heuristics.
      
      In the end, I'm not sure how worthwhile it all was: I only got a 
         1% decrease in code size
         1% decrease in allocation
      and I don't trust the runtime statistics enough to quote.
      
      Still, in doing all this I tidied up the code quite a bit, and 
      I understand it much better now, so I'm going to commit it.
      
      The main changes are in CoreUnfold, which has lots of new comments.
      Other changes:
      
        - litSize moves from Literal to CoreUnfold
        - interestingArg moves from SimplUtils to CoreUnfold
        - the default unfolding threshold (in StaticFlags) 
            reduces from 8 to 6 (since the size calculation 
            has changed a bit)
      
      b71760aa
  21. 02 Apr, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Float constants to top-level even in first full laziness pass · eaeca51e
      simonpj@microsoft.com authored
      This patch changes the compilation pipeline flags so that constants
      are floated to the top level even in the first full laziness pass.
      For some reason this was not done before.  Fixing this makes a big
      improvement in 'spectral/rewrite', and has zero effect on any other
      nofib benchmark.
      eaeca51e
  22. 26 Mar, 2009 1 commit
  23. 18 Mar, 2009 2 commits
    • Simon Marlow's avatar
      FIX unregisterised target by #ifdefing targetPlatform stuff · 1d34bd56
      Simon Marlow authored
      I'm not sure if this is the correct fix.  If targetPlatform is really
      NCG-specific, then maybe we should call it asmTargetPlatform or
      something.
      1d34bd56
    • simonpj@microsoft.com's avatar
      Add the notion of "constructor-like" Ids for rule-matching · 4bc25e8c
      simonpj@microsoft.com authored
      This patch adds an optional CONLIKE modifier to INLINE/NOINLINE pragmas, 
         {-# NOINLINE CONLIKE [1] f #-}
      The effect is to allow applications of 'f' to be expanded in a potential
      rule match.  Example
        {-# RULE "r/f" forall v. r (f v) = f (v+1) #-}
      
      Consider the term
           let x = f v in ..x...x...(r x)...
      Normally the (r x) would not match the rule, because GHC would be scared
      about duplicating the redex (f v). However the CONLIKE modifier says to
      treat 'f' like a constructor in this situation, and "look through" the
      unfolding for x.  So (r x) fires, yielding (f (v+1)).
      
      The main changes are:
        - Syntax
      
        - The inlinePragInfo field of an IdInfo has a RuleMatchInfo
          component, which records whether or not the Id is CONLIKE.
          Of course, this needs to be serialised in interface files too.
      
        - The occurrence analyser (OccAnal) and simplifier (Simplify) treat
          CONLIKE thing like constructors, by ANF-ing them
      
        - New function coreUtils.exprIsExpandable is like exprIsCheap, but
          additionally spots applications of CONLIKE functions
      
        - A CoreUnfolding has a field that caches exprIsExpandable
      
        - The rule matcher consults this field.  See 
          Note [Expanding variables] in Rules.lhs.
      
      On the way I fixed a lurking variable bug in the way variables are
      expanded.  See Note [Do not expand locally-bound variables] in
      Rule.lhs.  I also did a bit of reformatting and refactoring in
      Rules.lhs, so the module has more lines changed than are really
      different.
      4bc25e8c
  24. 17 Mar, 2009 1 commit
    • Simon Marlow's avatar
      Add fast event logging · 8b18faef
      Simon Marlow authored
      Generate binary log files from the RTS containing a log of runtime
      events with timestamps.  The log file can be visualised in various
      ways, for investigating runtime behaviour and debugging performance
      problems.  See for example the forthcoming ThreadScope viewer.
      
      New GHC option:
      
        -eventlog   (link-time option) Enables event logging.
      
        +RTS -l     (runtime option) Generates <prog>.eventlog with
                    the binary event information.
      
      This replaces some of the tracing machinery we already had in the RTS:
      e.g. +RTS -vg  for GC tracing (we should do this using the new event
      logging instead).
      
      Event logging has almost no runtime cost when it isn't enabled, though
      in the future we might add more fine-grained events and this might
      change; hence having a link-time option and compiling a separate
      version of the RTS for event logging.  There's a small runtime cost
      for enabling event-logging, for most programs it shouldn't make much
      difference.
      
      (Todo: docs)
      8b18faef
  25. 16 Mar, 2009 1 commit
  26. 13 Mar, 2009 1 commit
  27. 12 Mar, 2009 1 commit
    • Simon Marlow's avatar
      FIX #3079, dodgy parsing of LANGUAGE pragmas · c197fe60
      Simon Marlow authored
      I ended up rewriting this horrible bit of code, using (yikes) lazy I/O
      to slurp in the source file a chunk at a time.  The old code tried to
      read the file a chunk at a time, but failed with LANGUAGE pragmas
      because the parser for LANGUAGE has state and the state wasn't being
      saved between chunks.  We're still closing the Handle eagerly, so
      there shouldn't be any problems here.
      c197fe60
  28. 11 Mar, 2009 1 commit