1. 11 Feb, 2008 2 commits
    • rl@cse.unsw.edu.au's avatar
      Symbolic tags for simplifier phases · a33ae68a
      rl@cse.unsw.edu.au authored
      Every simplifier phase can have an arbitrary number of tags and multiple
      phases can share the same tags. The tags can be used as arguments to
      -ddump-simpl-phases to specify which phases are to be dumped.
      For instance, -ddump-simpl-phases=main will dump the output of phases 2, 1 and
      0 of the initial simplifier run (they all share the "main" tag) while
      -ddump-simpl-phases=main:0 will dump only the output of phase 0 of that run.
      At the moment, the supported tags are:
        main                 The main, staged simplifier run (before strictness)
        post-worker-wrapper  After the w/w split
        post-liberate-case   After LiberateCase
        final                Final clean-up run
      The names are somewhat arbitrary and will change in the future.
    • rl@cse.unsw.edu.au's avatar
      Allow -ddump-simpl-phases to specify which phases to dump · b4229ab6
      rl@cse.unsw.edu.au authored
      We can now say -ddump-simpl-phases=1,2 to dump only these two phases and
      nothing else.
  2. 04 Feb, 2008 2 commits
  3. 03 Feb, 2008 11 commits
  4. 10 Feb, 2008 4 commits
  5. 09 Feb, 2008 1 commit
  6. 07 Feb, 2008 3 commits
    • chak@cse.unsw.edu.au.'s avatar
    • simonpj@microsoft.com's avatar
      Adjust error message (Trac #2079) · 847abda2
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Redo inlining patch, plus some tidying up · fa1c8a7e
      simonpj@microsoft.com authored
      This adds back in the patch 
        * UNDO: Be a little keener to inline
      It originally broke the compiler because it tickled a Cmm optimisation bug,
      now fixed.  
      In revisiting this I have also make inlining a bit cleverer, in response to
      more examples from Roman. In particular
        * CoreUnfold.CallCtxt is a data type that tells something about
          the context of a call.  The new feature is that if the context is
          the argument position of a function call, we record both 
      	- whether the function (or some higher up function) has rules
      	- what the argument discount in that position is
          Either of these make functions keener to inline, even if it's
          in a lazy position
        * There was conseqential tidying up on the data type of CallCont.
          In particular I got rid of the now-unused LetRhsFlag
  7. 25 Jan, 2008 1 commit
  8. 08 Feb, 2008 2 commits
  9. 07 Feb, 2008 3 commits
  10. 05 Feb, 2008 1 commit
  11. 07 Feb, 2008 2 commits
  12. 06 Feb, 2008 2 commits
  13. 05 Feb, 2008 1 commit
  14. 06 Feb, 2008 2 commits
  15. 05 Feb, 2008 1 commit
  16. 06 Feb, 2008 1 commit
    • rl@cse.unsw.edu.au's avatar
      Teach cheapEqExpr about casts · a4835b8b
      rl@cse.unsw.edu.au authored
      Previously, cheapEqExpr would always return False if it encountered a cast.
      This was bad for two reasons. Firstly, CSE (which uses cheapEqExpr to compare
      expressions) never eliminated expressions which contained casts and secondly,
      it was inconsistent with exprIsBig. This patch fixes this.
  17. 05 Feb, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Inject implicit bindings before the simplifier (Trac #2070) · 5952ef0d
      simonpj@microsoft.com authored
      With constructor unpacking, it's possible for constructors and record
      selectors to have non-trivial code, which should be optimised before
      being fed to the code generator.  Example:
        data Foo = Foo { get :: {-# UNPACK #-} !Int }
      Then we do not want to get this:
        T2070.get =
          \ (tpl_B1 :: T2070.Foo) ->
          case tpl_B1 of tpl1_B2 { T2070.Foo rb_B4 ->
              let {
                ipv_B3 [Just S] :: GHC.Base.Int
                [Str: DmdType m]
                ipv_B3 = GHC.Base.I# rb_B4
              } in  ipv_B3 }
      If this goes through to codegen, we'll generate bad code.  Admittedly,
      this only matters when the selector is used in a curried way (e.g
      map get xs), but nevertheless it's silly.
      This patch injects the implicit bindings in SimplCore, before the
      simplifier runs.  That slows the simplifier a little, because it has
      to look at some extra bindings; but it's probably a slight effect.
      If it turns out to matter I suppose we can always inject them later,
      e.g. just before the final simplification.
      An unexpected (to me) consequence is that we get some specialisation rules
      for class-method selectors.  E.g. we get a rule
      	RULE  (==) Int dInt = eqInt
      There's no harm in this, but not much benefit either, because the 
      same result will happen when we inline (==) and dInt, but it's perhaps
      more direct.