1. 22 May, 2006 5 commits
    • simonpj@microsoft.com's avatar
      Prune imports · 1375c0a7
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Add deShadowBinds · 2c969ecc
      simonpj@microsoft.com authored
      Add CoreSubst.deShadowBinds, which removes shadowing from 
      a Core term.  I thought we wanted it for SpecConstr, but in 
      fact decided not to use it. Nevertheless, it's a useful sort
      of function to have around, and it has a particularly simple
    • simonpj@microsoft.com's avatar
      Inline in a call argument if the caller has RULES · a2c92ccc
      simonpj@microsoft.com authored
      This is an experimental change suggested by Roman.  Consider
      	{-# INLINE f #-}
      	f x y = ...
      	....(g (f a b))...
      where g has RULES.  Then we'd like to inline f, even though the context of
      the call is otherwise 100% boring -- g is lazy and we know nothing about
      x and y. 
      This patch just records in the continuation that f has rules.  And does so
      somewhat recursively...e.g.
      	...(g (h (f a b)))...
      where g has rules.  
    • simonpj@microsoft.com's avatar
      Add idHasRules · b7d8dffa
      simonpj@microsoft.com authored
      Add Id.idHasRules :: Id -> Bool, with the obvious semantics.
      This patch makes sense by itself, but it's just a tidy-up.
    • simonpj@microsoft.com's avatar
      Transmit inline pragmas faithfully · 39dd1943
      simonpj@microsoft.com authored
      *** WARNING: you will need to recompile your libraries 
      ***	     when you pull this patch (make clean; make)
      The inline pragma on wrapper-functions was being lost; this patch 
      makes it be transmitted faithfully.
      The reason is that we don't write the full inlining for a wrapper into
      an interface file, because it's generated algorithmically from its strictness
      info.  But previously the inline pragma as being written out only when we
      wrote out an unfolding, and hence it was lost for a wrapper.
      This makes a particular difference when a function has a NOINLINE[k] pragma.
      Then it may be w/w'd, and we must retain the pragma.  It's the only consistent
      thing to do really.
      The change does change the binary format of interface files, slightly.
      So you need to recompile all your libraries.
  2. 19 May, 2006 3 commits
    • simonpj@microsoft.com's avatar
      Improved RULE lhs typechecking; less dictionary sharing · 5a8a219c
      simonpj@microsoft.com authored
      See long comment with Simplify.tcSimplifyRuleLhs.
      Here's the key example:
        RULE "g"  forall x y z. g (x == y) (y == z) = ...
      Here, the two dictionaries are *identical*, but we do NOT WANT to
      generate the rule
      RULE	forall x::a, y::a, z::a, d1::Eq a
      	  f ((==) d1 x y) ((>) d1 y z) = ...
      Instead we want
      RULE	forall x::a, y::a, z::a, d1::Eq a, d2:Eq a
      	  f ((==) d1 x y) ((>) d2 y z) = ...
    • simonpj@microsoft.com's avatar
      Bug-fix for infix function definitions (parse/rename) · cbc86d74
      simonpj@microsoft.com authored
      Fix a crash provoked by
      	x `op` y = x
      	op       = True
      The trouble was that there is currently a single 'infix' flag for the
      whole group; and RnTypes.checkPrecMatch was therefore expecting the
      second eqn to have two args.
      This fixes the crash, and also or-s the infix flags for the various
      eqns together; previously it was just taken from the first eqn, which
      was wrong.
    • simonpj@microsoft.com's avatar
      Remove misleading comments · c2a3f586
      simonpj@microsoft.com authored
  3. 18 May, 2006 3 commits
    • simonpj@microsoft.com's avatar
      Fix a nasty continuation-duplication bug · b812bfb9
      simonpj@microsoft.com authored
      For a long-time mkDupableCont has had a bug that allows it to duplicate
      an arbitrary continuation, which it should not do, of course.
      The bug was that in the Select case of mkDupableCont we were calling
      prepareCaseCont, which did not duplicate the continuation if there is
      but a single alternative.  This is quite right in the case of the call
      in rebuildCase, but quite wrong in mkDupableCont.
      The bug manifest as follows. In the expression
      	f (case ... of { ..several alts.. })
      (when f is strict), we should transform to
      	f (...transformed arg...)
      The application of f should not be pushed down (see notes with the
      ArgOf case of mkDupableCont.  But that was not happening in an example
      like this (see how the call to f is pushed inwards).
      f (a `div` abs (b::Int))
          case b_afT of wild_aHa { GHC.Base.I# x_aHc ->
          let {
            $j_sIe :: GHC.Prim.Int# -> GHC.Base.Int
            $j_sIe =
      	\ (ds1_aHr [Nothing OneShot] :: GHC.Prim.Int#) ->
      	    (case ds1_aHr of ds2_aHq {
      	       __DEFAULT ->
      		 case a_afS of wild1_aHM { GHC.Base.I# x_aHO ->
      		 GHC.Base.I# (GHC.Base.divInt# x_aHO ds2_aHq)
      	       0 -> GHC.Err.divZeroError @ GHC.Base.Int
          } in 
            case GHC.Prim.>=# x_aHc 0 of wild1_aHe [Dead Nothing] {
      	GHC.Base.False ->
      	  let {
      	    ds1_aHr :: GHC.Prim.Int#
      	    ds1_aHr = GHC.Prim.negateInt# x_aHc
      	  } in  $j_sIe ds1_aHr;
      	GHC.Base.True -> $j_sIe x_aHc
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Comments only · ae019a20
      simonpj@microsoft.com authored
  4. 17 May, 2006 8 commits
  5. 10 May, 2006 1 commit
  6. 09 May, 2006 2 commits
  7. 08 May, 2006 4 commits
    • simonpj@microsoft.com's avatar
      Do not put wired-in things in interface files · ef61cbbc
      simonpj@microsoft.com authored
      There is no need for wired-in things to go into interface files; the compiler
      knows about them anyway.  Worse, it turns ou that if they are in an interface
      file, they may get read in with not-quite-right type info (e.g. GHC.Err.error),
      and the not-quite-right thing gets into the type envt.  Than it gets used 
      instead of the wired in thing.
      Best all round never to put them into interface files.  This is the way
      it used to be, but it looks as if it rotted away some time ago.
      (I noticed this when fixing unsafePerformIO stuff, becuase 'lazy' was getting
      an unfolding when it shouldn't.)
    • simonpj@microsoft.com's avatar
      Remove NOINLINE strictness hack · 302265d5
      simonpj@microsoft.com authored
      The stricteness analyser used to have a HACK which ensured that NOINLNE things
      were not strictness-analysed.  The reason was unsafePerformIO. Left to itself,
      the strictness analyser would discover this strictness for unsafePerformIO:
      	unsafePerformIO:  C(U(AV))
      But then consider this sub-expression
      	unsafePerformIO (\s -> let r = f x in 
      			       case writeIORef v r s of (# s1, _ #) ->
      			       (# s1, r #)
      The strictness analyser will now find that r is sure to be eval'd,
      and may then hoist it out.  This makes tests/lib/should_run/memo002
      Solving this by making all NOINLINE things have no strictness info is overkill.
      In particular, it's overkill for runST, which is perfectly respectable.
      	f x = runST (return x)
      This should be strict in x.
      So the new plan is to define unsafePerformIO using the 'lazy' combinator:
      	unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r)
      Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is 
      magically NON-STRICT, and is inlined after strictness analysis.  So
      unsafePerformIO will look non-strict, and that's what we want.
      Now we don't need the hack in the strictness analyser.
    • simonpj@microsoft.com's avatar
      Trim imports · 36b27193
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Trim imports · bbf41467
      simonpj@microsoft.com authored
  8. 05 May, 2006 1 commit
  9. 02 May, 2006 1 commit
  10. 05 May, 2006 3 commits
  11. 04 May, 2006 6 commits
    • simonpj@microsoft.com's avatar
    • simonpj@microsoft.com's avatar
      Fix a bug in rule matching · c276b9b6
      simonpj@microsoft.com authored
      The rule matcher uses a "rough-match" pre-filter, which was being too 
      aggressive.  The case looked like this:
      	rule:	f True
      	expr:	case e of x { True -> f x }
      Jues because x doesn't immediately look like True, we shouldn't say
      "can't match", but that is exactly what ruleCantMatch was doing.
    • simonpj@microsoft.com's avatar
      Fix constructor-specialisation bug · 64f00b23
      simonpj@microsoft.com authored
      The constructor-specialisation optimisation was not dealing with the case
      	(letrec ... in f) a1 a2
      We need to apply constructor specialisation in the letrec; previously
      we were leaving it untouched on the grounds that the function part of
      an application is almost always a variable.
      But in fact, float-in immediately precedes SpecConstr, so we can get
      these odd-looking applications.
    • simonpj@microsoft.com's avatar
      Fix precedence for records in derived Read · 381b1a62
      simonpj@microsoft.com authored
      The derived instance for Read of records wasn't quite right.
      	data T = T1 T | T2 { x::Int }
      The string "T1 T2 { x=2 }" should parse correctly as 
      	T1 (T2 {x=2})
      because of Haskell's odd precedence rules (record construction binds
      even more tightly than application), but the derived Read didn't take
      account of that.
      drvrun020 is the regression test
    • simonpj@microsoft.com's avatar
      Make rules available in RHS · dd09857f
      simonpj@microsoft.com authored
      After some earlier re-factoring, the code that was carefully trying
      to make RULES available in a function's own RHS was plain wrong.
      This commit fixes it.  Some programs should go faster!
    • simonpj@microsoft.com's avatar
  12. 03 May, 2006 1 commit
  13. 26 Apr, 2006 1 commit
  14. 27 Apr, 2006 1 commit