1. 07 Oct, 2010 11 commits
    • simonpj@microsoft.com's avatar
      Comments only · 2e979e27
      simonpj@microsoft.com authored
      2e979e27
    • simonpj@microsoft.com's avatar
      Implement auto-specialisation of imported Ids · 92267aa2
      simonpj@microsoft.com authored
      This big-ish patch arranges that if an Id 'f' is 
        * Type-class overloaded 
             f :: Ord a => [a] -> [a]
        * Defined with an INLINABLE pragma
             {-# INLINABLE f #-}
        * Exported from its defining module 'D'
      
      then in any module 'U' that imports D
      
      1. Any call of 'f' at a fixed type will generate 
         (a) a specialised version of f in U
         (b) a RULE that rewrites unspecialised calls to the
             specialised on
      
        e.g. if the call is (f Int dOrdInt xs) then the 
        specialiser will generate
           $sfInt :: [Int] -> [Int]
           $sfInt = <code for f, imported from D, specialised>
           {-# RULE forall d.  f Int d = $sfInt #-}
      
      2. In addition, you can give an explicit {-# SPECIALISE -#}
         pragma for the imported Id
           {-# SPECIALISE f :: [Bool] -> [Bool] #-}
         This too generates a local specialised definition, 
         and the corresponding RULE 
      
      The new RULES are exported from module 'U', so that any module
      importing U will see the specialised versions of 'f', and will
      not re-specialise them.
      
      There's a flag -fwarn-auto-orphan that warns you if the auto-generated
      RULES are orphan rules. It's not in -Wall, mainly to avoid lots of
      error messages with existing packages.
      
      Main implementation changes
      
       - A new flag on a CoreRule to say if it was auto-generated.
         This is persisted across interface files, so there's a small
         change in interface file format.
      
       - Quite a bit of fiddling with plumbing, to get the 
         {-# SPECIALISE #-} pragmas for imported Ids.  In particular, a
         new field tgc_imp_specs in TcGblEnv, to keep the specialise
         pragmas for imported Ids between the typechecker and the desugarer.
      
       - Some new code (although surprisingly little) in Specialise,
         to deal with calls of imported Ids
      92267aa2
    • simonpj@microsoft.com's avatar
      Make NameEnv back into type NameEnv a = UniqFM a · 861e1d55
      simonpj@microsoft.com authored
      I don't think the type distinction of declaring NameEnv with a newtype
      (as it was) is really useful to us. Moreover, VarEnv is a UniqFM, and
      I do sometimes want to build an envt with Ids and look up with Names.
      
      This may not be the last word on the subject.
      861e1d55
    • simonpj@microsoft.com's avatar
      Improve the rule-matcher · afd6da0d
      simonpj@microsoft.com authored
      Previously it was rejecting the match
      
        Template: forall s t. map s t
        Actual:   map Int t
      
      which should obviously be fine.  It turns out that this kind of match
      comes up when specialising.  By freshening that t we could avoid the
      difficulty, but morally the (forall t) binds t and the rule should
      be alpha-equivalent regardless of the forall'd variables.
      
      This patch makes it so, and incidentally makes matching a little
      more efficient.  See Note [Eta expansion] in VarEnv.
      afd6da0d
    • simonpj@microsoft.com's avatar
      Fix Trac #4345: simplifier bug · 5c248c7d
      simonpj@microsoft.com authored
      This is another long-standing bug, in which there was a possibility
      that a loop-breaker could lose its loop-breaker-hood OccInfo, 
      and then the simplifer re-simplified the expression. Result, either
      non-termination or, in the case of #4345, an unbound identifier.
      
      The fix is very simple, in Id.transferPolyIdInfo. 
      See Note [transferPolyIdInfo].
      5c248c7d
    • simonpj@microsoft.com's avatar
      Avoid redundant simplification · fb982282
      simonpj@microsoft.com authored
      When adding specialisation for imported Ids, I noticed that the
      Glorious Simplifier was repeatedly (and fruitlessly) simplifying the
      same term.  It turned out to be easy to fix this, because I already
      had a flag in the ApplyTo and Select constructors of SimplUtils.SimplCont.
      
      See Note [Avoid redundant simplification]
      fb982282
    • simonpj@microsoft.com's avatar
      Make the occurrence analyser deal correctly with RULES for imported Ids · d385c64c
      simonpj@microsoft.com authored
      This patch fixes a long-standing lurking bug, but it surfaced when I
      was adding specialisation for imported Ids.
      
      See Note [ImpRuleUsage], which explains the issue.   The solution
      seems more complicated than the problem really deserves, but I
      could not think of a simpler way, so I just bit the bullet and
      wrote the code.  Improvements welcome.
      d385c64c
    • simonpj@microsoft.com's avatar
      Make warning-free · d815b5b7
      simonpj@microsoft.com authored
      d815b5b7
    • simonpj@microsoft.com's avatar
      This is just white-space and layout · 8fa8c98e
      simonpj@microsoft.com authored
      (At least, I don't think there is anything else.)
      8fa8c98e
    • simonpj@microsoft.com's avatar
      Fix an ASSERT failure in FamInstEnv · e4b7186c
      simonpj@microsoft.com authored
      I added a lot of comments too, to explain the preconditions;
      esp Note [FamInstEnv]
      e4b7186c
    • simonpj@microsoft.com's avatar
      20607885
  2. 06 Oct, 2010 3 commits
  3. 04 Oct, 2010 1 commit
  4. 23 Sep, 2010 1 commit
  5. 06 Oct, 2010 3 commits
  6. 02 Oct, 2010 2 commits
  7. 29 Sep, 2010 1 commit
  8. 05 Oct, 2010 1 commit
    • Simon Marlow's avatar
      Fix a very rare crash in GHCi · 4a05e613
      Simon Marlow authored
      When a BCO with a zero-length bitmap was right at the edge of
      allocated memory, we were reading a word of non-existent memory.
      
      This showed up as a segfault in T789(ghci) for me, but the crash was
      extremely sensitive and went away with most changes.
      
      Also, optimised scavenge_large_bitmap a bit while I was in there.
      4a05e613
  9. 24 Sep, 2010 2 commits
  10. 03 Oct, 2010 1 commit
  11. 30 Sep, 2010 3 commits
  12. 29 Sep, 2010 2 commits
  13. 28 Sep, 2010 2 commits
  14. 25 Sep, 2010 2 commits
  15. 24 Sep, 2010 5 commits