1. 04 Jul, 2006 3 commits
  2. 24 Jul, 2006 1 commit
  3. 22 Jul, 2006 2 commits
    • simonpj@microsoft.com's avatar
      Add -fmono-pat-binds, and make it the default · 10ffe4f7
      simonpj@microsoft.com authored
      In Haskell 98, pattern bindings are generalised.  Thus in
      	(f,g) = (\x->x, \y->y)
      both f and g will get polymorphic types.  I have become convinced
      that generalisation for pattern-bound variables is just a bridge
      toof far. It is (I claim) almost never needed, and it adds significant
      complication.  (All the more so if we add bang patterns.)
      So the flag -fmono-pat-binds switches off generalisation for pattern
      bindings.  (A single variable is treated as a degnerate funtction
      Furthremore, as an experiment, I'm making it the default.  I want
      to see how many progarms fail with monomorphic pattern bindings.
      You can recover the standard behaviour with -fno-mono-pa-binds.
    • simonpj@microsoft.com's avatar
      Fix RULES lossage · 4fbd341b
      simonpj@microsoft.com authored
      Don Stewart and Duncan Coutts encountered the following situation.
      	f = <rhs>
      	{-# RULES f ... #-}
      where f is not exported, but appears in the inlinings of other
      functions that are exported.  Then what happened was that the desugarer
      produced this:
      	M.f = f
      	f = <rhs>
      where the rules get attached to the M.f. But since M.f's RHS is trivial
      (just f) it was unconditionally inlinined at all its call sites, 
      thereby losing the RULES attached to it.
      This *is* a fragile aspect of rules. However this fix solves the 
      problem by instead generating
      	f = M.f
      	M.f = <rhs>
      A pretty small chanage to the desugarer does the job.  It still feels
      a little fragile, bt it's certainly more robust than before.
  4. 17 Jul, 2006 1 commit
  5. 14 Jul, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Check for overlap-flag differences in hi files · 872a4a0f
      simonpj@microsoft.com authored
      I'd forgotten to compare the per-instance overlap flag when 
      comparing interface files, and that meant that consequential
      recompilations weren't being triggered when the only change
      was to add -fallow-overlapping-instances
      Fixes Trac bug #824
  6. 12 Jul, 2006 3 commits
    • simonpj@microsoft.com's avatar
      Comments and import trimming · 6bca92c3
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Experimental flag -fdicts-cheap · e1231b2b
      simonpj@microsoft.com authored
      This experimental flag, -fdicts-cheap, makes a let-binding that bind a
      value of dictionary type look cheap.  That in turn leads to more
      eta expansion.  Instead of
      	f = /\a. \(d1:Ord a). let d2:Ord [a] = dfOrd a d1 in
                       \(x:a). <stuff>
      which has arity 1, you get
      	f = /\a. \(d1:Ord a). \(x:a).
      	         let d2:Ord [a] = dfOrd a d1 in <stuff>
      Now f has arity 2.
      This can cretainly waste dictionary-construction work, if f is
      partially applied to its dictionary argument.  However it has knock-on
      effects.  Because f has arity 2, we won't float (f Int d) out of
      	\x. h (f Int d)
      Floating f out of this lambda makes it impossible for an h/f fusion
      rule to fire; and this unexpected loss of RULE application was the
      immediate reason for implementing this flag. (Roman Leshchinskiy came
      across this when working on array fusion.)
      I've implemented the change only in CoreUtils.arityType, which
      only affects eta expansion.  I thought of putting the change in
      exprIsCheap, which is a more systematic place (the former calls
      the latter) but
      	a) I wanted this under flag control, and the flags 
      	are not readily available to all callers of exprIsCheap
      	b) I'm not 100% convinced that this change is a good
      	idea, so it's reasonable to do the narrowest change
      	that solves the immediate problem.
    • Simon Marlow's avatar
  7. 06 Jul, 2006 1 commit
  8. 02 Jul, 2006 2 commits
    • Jan Rochel's avatar
      Z-Encode external-core output · 202712d3
      Jan Rochel authored
      HEAD doesn't z-encode external-core output (unlike 6.4). I suppose, that
      this is unwanted behaviour. It probably results from this patch:
      Fri Jan  6 17:30:19 CET 2006  simonmar
        * [project @ 2006-01-06 16:30:17 by simonmar]
        Add support for UTF-8 source files
      Z-encoding has been moved right to the back end.  Previously we
      used to Z-encode every identifier on the way in for simplicity,
      and only decode when we needed to show something to the user.
      Instead, we now keep every string in its UTF-8 encoding, and
      Z-encode right before printing it out.
    • Jan Rochel's avatar
      Add %local-tag to external core output · 99bab7d8
      Jan Rochel authored
      Hello, this is my first patch contributed to GHC. If there are any
      inadequacies about it (maybe like this introductory disclaimer), please
      let me know about it.
      So, the need for this patch arose, while I was involved with processing
      hcr files (external core output) and I noticed, that the output didn't
      fully conform to the specification [1].
      No %local-tags were used, which turned out to be a real nuisance as it
      was not possible to determine which VDEFs can be erased in a further
      optimization process and which ones are exported by the module.
      Since the specification does not define the meaning of the %local-tag, I
      assume, it makes sense, that it tags all functions, that are not
      exported by the module.
      The patch does not fully comply to the specification, as in my
      implementation a local tag may appear before a VDEF but not before a
      [1] An External Representation for the GHC Core Language
          (DRAFT for GHC5.02), page 3, line 1
  9. 04 Jul, 2006 1 commit
  10. 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.)
  11. 04 Jul, 2006 1 commit
  12. 29 Jun, 2006 5 commits
  13. 23 Jun, 2006 1 commit
  14. 20 Jun, 2006 4 commits
  15. 29 Jun, 2006 1 commit
  16. 27 Jun, 2006 2 commits
  17. 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
  18. 14 Jun, 2006 1 commit
  19. 25 Jun, 2006 1 commit
  20. 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'.
  21. 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
      Allow Template Haskell to be used with -prof · 6f5d7744
      Simon Marlow authored
      In order for this to work, you need to build the program first in the
      normal way (without -prof), and then again with -prof and a suitable
      -osuf (eg. -osuf p_o).  The compiler will pick up the object files
      from the normal way for running TH expressions, when it sees -prof
      together with -osuf.  If you omit the -osuf, you get an error message:
          Dynamic linking required, but this is a non-standard build (eg. prof).
          You need to build the program twice: once the normal way, and then
          in the desired way using -osuf to set the object file suffix.
      If you use -osuf, but haven't built the program the normal way first,
      then you see:
          cannot find normal object file `TH_genExLib.o'
          while linking an interpreted expression
      Documentation to follow.
      Fixes: #651