Skip to content
  • Simon Peyton Jones's avatar
    [project @ 2000-09-07 16:32:23 by simonpj] · 4e6d5798
    Simon Peyton Jones authored
    A list of simplifier-related stuff, triggered
    	by looking at GHC's performance.
    
    	I don't guarantee that this lot will lead to
    	a uniform improvement over 4.08, but it it should
    	be a bit better.  More work probably required.
    
    
    * Make the simplifier's Stop continuation record whether the expression being
      simplified is the RHS of a thunk, or (say) the body of a lambda or case RHS.
      In the thunk case we want to be a bit keener about inlining if the type of
      the thunk is amenable to update in place.
    
    * Fix interestingArg, which was being too liberal, and hence doing
      too much inlining.
    
    * Extended CoreUtils.exprIsCheap to make two more things cheap:
        - 	case (coerce x) of ...
        -   let x = y +# z
      This makes a bit more eta expansion happen.  It was provoked by
      a program of Marcin's.
    
    * MkIface.ifaceBinds.   Make sure that we emit rules for things
      (like class operations) that don't get a top-level binding in the
      interface file.  Previously such rules were silently forgotten.
    
    * Move transformRhs to *after* simplification, which makes it a
      little easier to do, and means that the arity it computes is
      readily available to completeBinding.  This gets much better
      arities.
    
    * Do coerce splitting in completeBinding. This gets good code for
    	newtype CInt = CInt Int
    
    	test:: CInt -> Int
    	test x = case x of
    	      	   1 -> 2
    	      	   2 -> 4
    	      	   3 -> 8
    	      	   4 -> 16
    	      	   _ -> 0
    
    * Modify the meaning of "arity" so that during compilation it means
      "if you apply this function to fewer args, it will do virtually
      no work".   So, for example
    	f = coerce t (\x -> e)
      has arity at least 1.  When a function is exported, it's arity becomes
      the number of exposed, top-level lambdas, which is subtly different.
      But that's ok.
    
      I removed CoreUtils.exprArity altogether: it looked only at the exposed
      lambdas.  Instead, we use exprEtaExpandArity exclusively.
    
      All of this makes I/O programs work much better.
    4e6d5798