1. 10 Dec, 2006 1 commit
  2. 09 Dec, 2006 1 commit
  3. 07 Dec, 2006 5 commits
  4. 06 Dec, 2006 2 commits
    • chak@cse.unsw.edu.au.'s avatar
      Kind sigs in associated data/newtype family decls may be omitted · 526a19e9
      chak@cse.unsw.edu.au. authored
      * This is only a slight generalisation of the parser, so that family
        declarations on the toplevel and in classes are uniform.
      * I didn't allow that right away as it is a bit tricky to avoid reduce/reduce 
    • simonpj@microsoft.com's avatar
      Improve dependency analysis; makes more dictionaries inlinable · 94cbe022
      simonpj@microsoft.com authored
      I recentl changed the scoring system used by dependency analysis for
      recursive bindings, that it used the *form* of the RHS of a binding,
      rather than just its type. In doing so I inadvertently made recursive
      dictionary bindings unravel less well, because I'd missed the case
      of 	c = /\a. C (...) (...)
      This patch fixes the problem.  A good example is the instance for
      Monad (ST s) or Show (ST s a) in GHC.ST.  It's vital for these
      dictionaries to be inlinable.
  5. 04 Dec, 2006 1 commit
  6. 03 Dec, 2006 1 commit
    • Ian Lynagh's avatar
      MERGE: In hashExpr, use Word32 rather than relying on wrapping behaviour of Int · df95de0b
      Ian Lynagh authored
      Fixes #952, as it turns out.
      When compiling via C, we are at the mercy of C's undefined behaviour
      with respect to overflow of signed integer operations, and this was
      biting us here.
      Perhaps we should always add the -fwrapv flag to gcc, but since
      Haskell doesn't define overflow on Int either, it seemed the right
      thing to do to fix this code anyway.
  7. 01 Dec, 2006 2 commits
  8. 29 Nov, 2006 8 commits
    • simonpj@microsoft.com's avatar
      Remove trace · b20a90d8
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Remove bogus comment · 4706dd57
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Teach SpecConstr how to handle mutually-recursive functions · 9fad5a80
      simonpj@microsoft.com authored
      Roman found cases where it was important to do SpecConstr for
      mutually-recursive definitions.  Here is one:
      	foo :: Maybe Int -> Int
      	foo Nothing  = 0
      	foo (Just 0) = foo Nothing
      	foo (Just n) = foo (Just (n-1))
      By the time SpecConstr gets to it, it looks like this:
      	lvl = foo Nothing
      	foo Nothing  = 0
      	foo (Just 0) = lvl
      	foo (Just n) = foo (Just (n-1))
      Happily, it turns out to be rather straightforward to generalise the
      transformation to mutually-recursive functions.  Look, ma, only 4 
      extra lines of ocde!
    • simonpj@microsoft.com's avatar
      Improve the loop-breaking heuristics · 1dca1587
      simonpj@microsoft.com authored
      The loop-breaking heuristics were making it a high priority to
      avoid choosing a variable as a loop breaker if its *type* was a 
      data type.  The reason is that it's very good to be able to "see"
      constructor applications.
      But it's only good if the constructor application is *visible*, 
      so that is what I test for now.  I found a case (when testing 
      SpecConstr) where I had a Rec like this:
      	rec { lvl = foo Nothing
      	      foo = ...
      	        RULE foo Nothing = ...
      Even if lvl has a data type, it's much better to make lvl the loop
      breaker, not foo, so that foo's RULE is visible in lvl's RHS.
    • simonpj@microsoft.com's avatar
      Comments only · beade0a1
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Make SpecConstr work right for nullary constructors · 4d109022
      simonpj@microsoft.com authored
      For totally stupid reasons, SpecConstr didn't work for the (particularly
      easy) case of nullary constructors like True and False.  I just had some
      equations in the wrong order, so that a Var case came first, which 
      matches a nullary constructor, with the constructor-application case
      The fix is easy.  I did a bit of refactoring at the same time.
    • wolfgang.thaller@gmx.net's avatar
      x86_64 NCG: fix register usage for CALLs · 561e5742
      wolfgang.thaller@gmx.net authored
      For varargs calls, CALL reads the %al register; record that fact for the benefit of the
      register allocator.
      (There was a previous attempt to do this, but it was broken.)
    • andy@galois.com's avatar
      TickBox representation change · 8100cd43
      andy@galois.com authored
      This changes the internal representation of TickBoxes,
              Note (TickBox "module" n)  <expr>
              case tick<module,n> of
                _ -> <expr>
      tick has type :: #State #World, when the module and tick numbe
      are stored inside IdInfo.
      Binary tick boxes change from
               Note (BinaryTickBox "module" t f) <expr>
                btick<module,t,f> <expr>
      btick has type :: Bool -> Bool, with the module and tick number
      stored inside IdInfo.
  9. 01 Nov, 2006 1 commit
  10. 29 Nov, 2006 1 commit
  11. 28 Nov, 2006 1 commit
  12. 24 Nov, 2006 2 commits
  13. 20 Nov, 2006 1 commit
    • wolfgang.thaller@gmx.net's avatar
      i386-darwin: disable use of code stubs for dynamic linking · 5cfeedcc
      wolfgang.thaller@gmx.net authored
      We can't use lazy binding for tail-calls accross shared libraries, because dyld
      will crash due to incorrect stack layout. We can't get the stack alignment right for
      both cross-library tailcalls and foreign calls, so we have to bypass the stub code altogether
      and load the address to branch to from the non-lazy pointer table.
  14. 22 Oct, 2006 2 commits
  15. 25 Nov, 2006 1 commit
  16. 24 Nov, 2006 9 commits
    • simonpj@microsoft.com's avatar
      Fix constraint handling for lazy patterns · 36d207aa
      simonpj@microsoft.com authored
      Lazy patterns are quite tricky!  Consider
      	f ~(C x) = 3
      Can the Num constraint from the 3 be discharged by a Num dictionary
      bound by the pattern?  Definitely not!  
      See Note [Hopping the LIE in lazy patterns] in TcPat
      The type checker wasn't ensuring this, and that was causing all
      manner of strange things to happen.  It actually manifested as a
      strictness bug reported by Sven Panne.
      I've added his test case as tcrun040.
    • simonpj@microsoft.com's avatar
      Make SpecConstr more aggressive, by neglecting reboxing · d8a34b36
      simonpj@microsoft.com authored
      SpecConstr was conservative about avoiding reboxing (see Note [Reboxing])
      but that meant it lost useful opportunities.  This patch makes it much
      more aggressive, but at the risk of doing some reboxing.
      Actually, the strictness analyser has the same property (it's possible
      for it to generate reboxing code, and thus increase allocation), but we
      don't worry so much about that.  Maybe we should.
      Ideally, one would do some more sophisticated analysis that spotted
      the reboxing cases without excluding the useful ones.  
      But meanwhile, let's try this. 
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Improve handling of implicit parameters · 2e9952b7
      simonpj@microsoft.com authored
      A message to Haskell Cafe from Grzegorz Chrupala made me realise that
      GHC was not handling implicit parameters correctly, when it comes to
      choosing the variables to quantify, and ambiguity tests.  Here's the 
      note I added to TcSimplify:
      Note [Implicit parameters and ambiguity] 
      What type should we infer for this?
      	f x = (show ?y, x::Int)
      Since we must quantify over the ?y, the most plausible type is
      	f :: (Show a, ?y::a) => Int -> (String, Int)
      But notice that the type of the RHS is (String,Int), with no type 
      varibables mentioned at all!  The type of f looks ambiguous.  But
      it isn't, because at a call site we might have
      	let ?y = 5::Int in f 7
      and all is well.  In effect, implicit parameters are, well, parameters,
      so we can take their type variables into account as part of the
      "tau-tvs" stuff.  This is done in the function 'FunDeps.grow'.
      The actual changes are in FunDeps.grow, and the tests are
      	tc219, tc219
    • simonpj@microsoft.com's avatar
      Fix name-capture bug in rule matching · dfcbc18e
      simonpj@microsoft.com authored
      The matching algorithm for RULES should respect alpha-conversion, but it
      wasn't doing so.  In particular, if the names of the template variables
      clashed with a variable in scope at the call site, bad things could happen
      (it showed up as a CoreLint failure when compiling nofib/real/parser)
      This patch fixes the problem; see Note [Template binders]
      Test is in simplCore/should_compile/spec002, but nofib -O2 in
      	real/parser, real/fulsom
    • simonpj@microsoft.com's avatar
      Improve hashing of expressions · 9ba6b031
      simonpj@microsoft.com authored
      We were getting too many cases where different expressions map to the
      same hash code (which shows up in CSE). This patch tries to improve
      the hash algorithm a bit.
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Gather constraints in program order · ecd655aa
      simonpj@microsoft.com authored
      Provoked by a suggestion of Simon's, this patch makes a half-hearted attempt
      to gather constraints in program order, so that we tend to report an error
      at its first occurrence, rather than its last.  Examples:
      	mdofail001, tcfail015
      It's "half-hearted" because generally-speaking the typechecker does not
      guaranteed to keep constraints in order; it treats them as a set.  Nevertheless
      this very small change seems to improve matters, so it seems a good one.
  17. 23 Nov, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Simplify TcSimplify, by removing Free · a3a15a64
      simonpj@microsoft.com authored
      For a long time TcSimplify used a three-way classification of constraints, 
      into 	Free
      (see the data type WhatToDo).  In the new world of implication constraints,
      the Free case does not make so much sense, and I managed to elminate it
      altogether, thus simplifying the story somewhat.  Now WhatToDo has constructors
      There should be no change in behaviour.