1. 01 Aug, 2000 1 commit
    • simonpj's avatar
      [project @ 2000-08-01 09:08:25 by simonpj] · fe69f3c1
      simonpj authored
      Simon's Marktoberdorf Commits
      
      1.  Tidy up the renaming story for "system binders", such as
      dictionary functions, default methods, constructor workers etc.  These
      are now documented in HsDecls.  The main effect of the change, apart
      from tidying up, is to make the *type-checker* (instead of the
      renamer) generate names for dict-funs and default-methods.  This is
      good because Sergei's generic-class stuff generates new classes at
      typecheck time.
      
      
      2.  Fix the CSE pass so it does not require the no-shadowing invariant.
      Keith discovered that the simplifier occasionally returns a result
      with shadowing.  After much fiddling around (which has improved the
      code in the simplifier a bit) I found that it is nearly impossible to
      arrange that it really does do no-shadowing.  So I gave up and fixed
      the CSE pass (which is the only one to rely on it) instead.
      
      
      3. Fix a performance bug in the simplifier.  The change is in
      SimplUtils.interestingArg.  It computes whether an argment should 
      be considered "interesting"; if a function is applied to an interesting
      argument, we are more likely to inline that function.
      Consider this case
      	let x = 3 in f x
      The 'x' argument was considered "uninteresting" for a silly reason.
      Since x only occurs once, it was unconditionally substituted, but
      interestingArg didn't take account of that case.  Now it does.
      
      I also made interestingArg a bit more liberal.  Let's see if we
      get too much inlining now.
      
      
      4.  In the occurrence analyser, we were choosing a bad loop breaker.
      Here's the comment that's now in OccurAnal.reOrderRec
      
          score ((bndr, rhs), _, _)
      	| exprIsTrivial rhs 	   = 3	-- Practically certain to be inlined
      		-- Used to have also: && not (isExportedId bndr)
      		-- But I found this sometimes cost an extra iteration when we have
      		--	rec { d = (a,b); a = ...df...; b = ...df...; df = d }
      		-- where df is the exported dictionary. Then df makes a really
      		-- bad choice for loop breaker
      
      I also increased the score for bindings with a non-functional type, so that
      dictionaries have a better chance of getting inlined early
      
      
      5. Add a hash code to the InScopeSet (and make it properly abstract)
      This should make uniqAway a lot more robust.  Simple experiments suggest
      that uniqAway no longer gets into the long iteration chains that it used
      to.
      
      
      6.  Fix a bug in the inliner that made the simplifier tend to get into
      a loop where it would keep iterating ("4 iterations, bailing out" message).
      In SimplUtils.mkRhsTyLam we float bindings out past a big lambda, thus:
      	x = /\ b -> let g = \x -> f x x
      		    in E
      becomes
      	g* = /\a -> \x -> f x x
      	x = /\ b -> let g = g* b in E
      	
      It's essential that we don't simply inling g* back into the RHS of g,
      else we will be back to square 1.  The inliner is meant not to do this
      because there's no benefit to the inlining, but the size calculation
      was a little off in CoreUnfold.
      
      
      7.  In SetLevels we were bogus-ly building a Subst with an empty in-scope
      set, so a WARNING popped up when compiling some modules.  (knights/ChessSetList
      was the example that tickled it.)  Now in fact the warning wasn't an error,
      but the Right Thing to do is to carry down a proper Subst in SetLevels, so
      that is what I have now done.  It is very little more expensive.
      fe69f3c1
  2. 27 Jul, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-07-27 09:02:05 by sewardj] · 023fea0f
      sewardj authored
      Redo the sparc Ccall machinery, so as to correctly handle the case
      where one or more of the args to a Ccall is itself a Ccall.  Prior to
      the advent of the Stix inliner, this could never happen, but now it
      does.
      023fea0f
  3. 26 Jul, 2000 3 commits
  4. 24 Jul, 2000 1 commit
    • simonmar's avatar
      [project @ 2000-07-24 14:29:55 by simonmar] · 1da7b45d
      simonmar authored
      Some changes to the way FFI decls are handled:
      
        - a foreign export dynamic which returns a newtype of
          an Addr now works correctly.  Similarly for foreign label.
      
        - unlifted types are not allowed in the arguments of a foreign
          export.  Previously we generated incorrect code for these cases.
      
      Newtypes in FFI declarations now work everywhere they should, as far
      as I can see.
      
      These changes will be backported into 4.08.1.
      1da7b45d
  5. 23 Jul, 2000 1 commit
    • panne's avatar
      [project @ 2000-07-23 10:53:11 by panne] · c8a6996a
      panne authored
      Strictfp-like behaviour is the default now, which can be switched off
      via -fexcess-precision. (Has anybody a better name for this option?)
      c8a6996a
  6. 21 Jul, 2000 1 commit
  7. 18 Jul, 2000 3 commits
  8. 17 Jul, 2000 5 commits
  9. 16 Jul, 2000 2 commits
    • panne's avatar
      [project @ 2000-07-16 21:10:48 by panne] · 2869e22f
      panne authored
      This commit tries to fix the discrepancies between the results of
      floating point calculations during runtime and compile time, see
      e.g. fptools/ghc/tests/numeric/should_run/arith008.hs. Part of the
      story was the fact that floating point values are represented as
      Rationals in GHC and therefore never lost precision, at least for the
      operations for which constant folding is done. To compensate for this,
      before and after floating point operations the operands are
      temporarily converted to/from Float/Double. This is wrong, because
      host architecture and target architecture are confused this way, but
      in a non-cross-compiling scenario it works.
      2869e22f
    • panne's avatar
      [project @ 2000-07-16 20:58:48 by panne] · c5684f87
      panne authored
      Added new -fstrictfp flag
      c5684f87
  10. 15 Jul, 2000 1 commit
  11. 14 Jul, 2000 8 commits
    • lewie's avatar
      [project @ 2000-07-14 23:54:06 by lewie] · f6d9b940
      lewie authored
      Functional Dependencies were not getting simplified away when the dictionary
      that generated them was simplified by instance resolution.  Fixed.
      f6d9b940
    • simonpj's avatar
      [project @ 2000-07-14 13:38:55 by simonpj] · 19c34632
      simonpj authored
      Fix typeKind
      19c34632
    • simonpj's avatar
      [project @ 2000-07-14 13:38:39 by simonpj] · 6a562dd5
      simonpj authored
      Arrange that type signatures work right.  Consider:
      
      	   module A
      		import M( f )
      		f :: Int -> Int
      		f x = x
      
      Here, the 'f' in the signature isn't ambiguous; it
      refers to the locally defined f.  (This isn't clear in
      the Haskell 98 report, but it will be.)
      6a562dd5
    • simonpj's avatar
      [project @ 2000-07-14 13:37:53 by simonpj] · 71352675
      simonpj authored
      Wibbles in the new kind-checking stuff
      71352675
    • simonpj's avatar
      [project @ 2000-07-14 13:37:07 by simonpj] · 3d76aecb
      simonpj authored
      Add a type signature
      3d76aecb
    • simonpj's avatar
      [project @ 2000-07-14 13:36:33 by simonpj] · f39f5abb
      simonpj authored
      Tidy up newMutTyVar/newSigTyVar
      f39f5abb
    • simonpj's avatar
      [project @ 2000-07-14 08:17:36 by simonpj] · 77a8c0db
      simonpj authored
      This commit completely re-does the kind-inference mechanism.
      Previously it was inter-wound with type inference, but that was
      always hard to understand, and it finally broke when we started
      checking for ambiguity when type-checking a type signature (details
      irrelevant).
      
      So now kind inference is more clearly separated, so that it never
      takes place at the same time as type inference.  The biggest change
      is in TcTyClsDecls, which does the kind inference for a group of
      type and class declarations.  It now contains comments to explain
      how it all works.
      
      There are also comments in TypeRep which describes the slightly
      tricky way in which we deal with the fact that kind 'type' (written
      '*') actually has 'boxed type' and 'unboxed type' as sub-kinds.
      The whole thing is a bit of a hack, because we don't really have 
      sub-kinding, but it's less of a hack than before.
      
      A lot of general tidying up happened at the same time.
      In particular, I removed some dead code here and there
      77a8c0db
    • simonpj's avatar
      [project @ 2000-07-14 08:14:53 by simonpj] · 8d873902
      simonpj authored
      Remove dead code
      8d873902
  12. 13 Jul, 2000 2 commits
  13. 12 Jul, 2000 2 commits
  14. 11 Jul, 2000 9 commits