1. 03 Jul, 2006 1 commit
    • simonpj@microsoft.com's avatar
      The dict-bindings in an IPBinds need not be in dependency order · 5c9c3660
      simonpj@microsoft.com authored
      This appears to be a long-standing bug, discovered by BlueSpec 
      (ravi@bluespec.com), Trac bug #795
      The problem was that in an IP binding group, the dict bindings
      aren't necessarily in dependency order; and if they aren't 
      we get a core-lint error.
      Test tc203 checks this case.  (Though whether it shows up at
      all depends a bit on accidental factors of binding ordering.)
  2. 04 Jul, 2006 1 commit
  3. 29 Jun, 2006 11 commits
  4. 23 Jun, 2006 1 commit
  5. 20 Jun, 2006 8 commits
  6. 29 Jun, 2006 1 commit
  7. 27 Jun, 2006 3 commits
  8. 26 Jun, 2006 3 commits
    • simonpj@microsoft.com's avatar
      More SpecConstr tuning · b5f43414
      simonpj@microsoft.com authored
      For some reason, SpecConstr wasn't taking account of let-bound constructors:
      	let v = Just 4
      	in ...(f v)...
      Now it does.  An easy fix fortunately.
    • simonpj@microsoft.com's avatar
      Improve consistency checking for derived instances · 7f0ce617
      simonpj@microsoft.com authored
      This patch arranges that derived instances use the same instance-decl
      checking code as user-defined instances.  That gives greater consistency
      in error messages.
      Furthermore, the error description if this consistency check fails is now
      much more explicit.  For example, drvfail003 now says
           Variable occurs more often in a constraint than in the instance head
             in the constraint: Show (v (v a))
           (Use -fallow-undecidable-instances to permit this)
           In the derived instance
             instance (Show (v (v a))) => Show (Square_ v w a)
    • simonpj@microsoft.com's avatar
  9. 14 Jun, 2006 1 commit
  10. 25 Jun, 2006 1 commit
  11. 24 Jun, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Improve RULE matching a bit more · 7d44782f
      simonpj@microsoft.com authored
      Consider this example (provided by Roman)
      	foo :: Int -> Maybe Int -> Int
      	foo 0 (Just n) = n
      	foo m (Just n) = foo (m-n) (Just n)
      SpecConstr sees this fragment:
      	case w_smT of wild_Xf [Just A] {
      	  Data.Maybe.Nothing -> lvl_smf;
      	  Data.Maybe.Just n_acT [Just S(L)] ->
      	    case n_acT of wild1_ams [Just A] { GHC.Base.I# y_amr [Just L] ->
      	    $wfoo_smW (GHC.Prim.-# ds_Xmb y_amr) wild_Xf
      and correctly generates the rule
      	RULES: "SC:$wfoo1" [0] __forall {y_amr [Just L] :: GHC.Prim.Int#
      					  sc_snn :: GHC.Prim.Int#}
      	  $wfoo_smW sc_snn (Data.Maybe.Just @ GHC.Base.Int (GHC.Base.I# y_amr))
      	  = $s$wfoo_sno y_amr sc_snn ;]
      BUT we must ensure that this rule matches in the original function!
      Note that the call to $wfoo is
      	    $wfoo_smW (GHC.Prim.-# ds_Xmb y_amr) wild_Xf
      During matching we expand wild_Xf to (Just n_acT).  But then we must also
      expand n_acT to (I# y_amr).  And we can only do that if we look up n_acT
      in the in-scope set, because in wild_Xf's unfolding it won't have an unfolding
      at all. 
      Happily, fixing the bug is easy: add a call to 'lookupRnInScope' in the 
      (Var v2) case of 'match'.
  12. 23 Jun, 2006 2 commits
  13. 22 Jun, 2006 2 commits
  14. 21 Jun, 2006 4 commits
    • simonpj@microsoft.com's avatar
      Comment only · 5542157c
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Transfer INLINE to specialised functions · 8d227e35
      simonpj@microsoft.com authored
      When the Specialise pass generates a specialised copy of a function,
      it should transfer the INLINE information to the specialised function.
      Otherwise, whether or not the INLNE happens can depend on whether
      specialisation happens, which seems wrong.  See Note [Inline specialisation]
      in Specialise.lhs
      Here's the example Roman reported
          primWriteMU :: UAE e => MUArr e s -> Int -> e -> ST s ()
          {-# INLINE primWriteMU #-}
          primWriteMU = writeMBU . unMUAPrim
          The problem is that primWriteMU doesn't get inlined *sometimes*, which
          results in code like
          case Data.Array.Parallel.Unlifted.Flat.UArr.$sprimWriteMU
      	    @ s11_X1nJ
      	    (GHC.Base.I# sc_s27F)
      	    of wild3_a1Dd { (# new_s1_X1F9, r_a1Dc #) -> ...
      Note the fact that we have a call to the *specialised* $sprimWriteMU.
    • simonpj@microsoft.com's avatar
      Arity and eta-expansion tuning · 182ce7e2
      simonpj@microsoft.com authored
      Roman found that 
          loop :: STRef s a -> Int -> ST s Int
          loop ref n = case n of
                         0 -> return n
                         n -> loop ref (n-1)
      wasn't eta-expanding nicely, despite the 'state hack'
      (see Id.isStateHackType).  The reason was two-fold:
        a) a bug in CoreUtils.arityType (the Var case)
        b) the arity of a recursive function was not being
      	exposed in its RHS (see commments with
      The commit fixes both.  
    • Simon Marlow's avatar
      documentation for TH w/ profiling · d4f8ccee
      Simon Marlow authored