1. 24 Mar, 2008 2 commits
  2. 23 Mar, 2008 1 commit
  3. 20 Mar, 2008 1 commit
  4. 22 Mar, 2008 1 commit
  5. 20 Mar, 2008 2 commits
    • Ian Lynagh's avatar
    • chevalier@alum.wellesley.edu's avatar
      Handle hierarchical module names in External Core tools · 6b085eea
      chevalier@alum.wellesley.edu authored
      I updated the parser to handle hierarchical module names (with package names)
      the way GHC is currently printing them out in External Core.
      Beware kludgy use of z-encoding and gratutious copy-pasta from GHC.
      You can now use the stand-alone Core parser to parse a very simple
      GHC-generated .hcr file (progress!) but not to typecheck or interpret it
      (the typechecker/interpreter don't snarf in the right libraries yet, among
      other things.) And, the parser is still incomplete in that it doesn't handle
      programs with newtypes/GADTs/etc. whose syntax has changed since 2003. In
      other words: probably don't try to use this yet.
  6. 19 Mar, 2008 2 commits
    • chevalier@alum.wellesley.edu's avatar
      Improve hierarchical module name handling in MkExternalCore · 87c93cf5
      chevalier@alum.wellesley.edu authored
      It's easier for the External Core parser if MkExternalCore prints
      module names like:
      rather than like:
      (which it was doing before.)
      So now we z-encode the hierarchical module-name part of a module
      name, but don't z-encode the ':'.
      I also removed some old comments that don't seem relevant anymore.
    • chevalier@alum.wellesley.edu's avatar
      Fixed remaining warning in coreSyn/MkExternalCore · d5a9ee0e
      chevalier@alum.wellesley.edu authored
      There was a (suppressed) warning about an incomplete pattern match in make_alt. This was because the DEFAULT alt never has variable bindings. I thought it would be better to check that case and panic if it happens than to have an incomplete pattern. It's still not great, but at least now we don't have to suppress any warnings in this file.
  7. 17 Mar, 2008 4 commits
  8. 16 Mar, 2008 1 commit
  9. 17 Mar, 2008 2 commits
  10. 11 Mar, 2008 1 commit
  11. 16 Mar, 2008 1 commit
  12. 15 Mar, 2008 1 commit
  13. 16 Mar, 2008 2 commits
  14. 15 Mar, 2008 2 commits
  15. 13 Mar, 2008 1 commit
  16. 07 Feb, 2008 1 commit
    • Simon Marlow's avatar
      Tweaks to stack squeezing · 53a442f1
      Simon Marlow authored
      1. We weren't squeezing two frames if one of them was a marked update
         frame.  This is easy to fix.
      2. The heuristic to decide whether to squeeze was a little
         conservative.  It's worth copying 3 words to save an update frame.
  17. 13 Mar, 2008 3 commits
    • chak@cse.unsw.edu.au.'s avatar
      Some cleanup in TcSimplify.reduceContext · b5a8dd88
      chak@cse.unsw.edu.au. authored
      - Makes this horrid function a bit better - and shorter!
      - Also gets rid of another API function of TcTyFuns
    • chak@cse.unsw.edu.au.'s avatar
      Properly normalise reduced dicts · 3bbdfc75
      chak@cse.unsw.edu.au. authored
      - Another chapter in the never-ending TcSimplify.reduceContext saga: after
        context reduction of wanted dicts it is not sufficient to normalise them
        wrt to the wanted equalities.  We also need to take top-level equalities
        into account.  (In fact, we probably also have to normalise wrt to given
        equalities, but I have left that open for the moment - but added a TODO
      - This finally eliminates substEqInDictInsts from TcTyFuns interface and
        suggest some further possible clean up (which will be in a separate patch).
      Thanks to Roman for the intricate example that uncovered this bug.
    • rl@cse.unsw.edu.au's avatar
      Bump mAX_NDP_PROD to 5 · 11a4f9a9
      rl@cse.unsw.edu.au authored
  18. 12 Mar, 2008 3 commits
  19. 10 Mar, 2008 1 commit
    • chevalier@alum.wellesley.edu's avatar
      First cut at reviving the External Core tools · 27658502
      chevalier@alum.wellesley.edu authored
      I updated the External Core AST to be somewhat closer to reality (where reality is defined by the HEAD), and got all the code to compile under GHC 6.8.1. (That means it works, right?)
      Major changes:
      - Added a Makefile.
      - Core AST:
          - Represented package names and qualified module names.
          - Added type annotation on Case exps.
          - Changed Coerce to Cast.
          - Cleaned up representation of qualified/unqualified names.
          - Fixed up wired-in module names (no more "PrelGHC", etc.)
      - Updated parser/interpreter/typechecker/prep for the new AST.
      - Typechecker:
          - Used a Reader monad to pass around the global environment and top module name.
          - Added an entry point to check a single expression.
      - Prep:
          - Got rid of typeofExp; it's now defined in terms of the typechecker.
  20. 09 Mar, 2008 2 commits
  21. 06 Mar, 2008 3 commits
    • simonpj@microsoft.com's avatar
      Don't expose the unfolding of dictionary selectors without -O · 74d5597e
      simonpj@microsoft.com authored
      When compiling without -O we were getting code like this
      	f x = case GHC.Base.$f20 of
      		  :DEq eq neq -> eq x x
      But because of the -O the $f20 dictionary is not available, so exposing
      the dictionary selector was useless.  Yet it makes the code bigger!
      Better to get
      	f x = GHC.Base.== GHC.Bsae.$f20 x x
      This patch suppresses the implicit unfolding for dictionary selectors
      when compiling without -O.  We could do the same for other implicit
      Ids, but this will do for now.
      There should be no effect when compiling with -O.  Programs should
      be smaller without -O and may run a tiny bit slower.
    • simonpj@microsoft.com's avatar
      Fix Trac #783: improve short-cutting literals in the type checker · 0a8ad35f
      simonpj@microsoft.com authored
      The Inst.shortCutIntLit mechanism in the type checker was missing cases
      where a floating-point literal was given without an explicit decimal point.
      As a result, programs with lots of floating-point literals (without decimals)
      ended up with massive Static Reference Tables.  This is not cool.  See
      comments with Trac #783 for details.
    • simonpj@microsoft.com's avatar
  22. 07 Mar, 2008 1 commit
  23. 06 Mar, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Improve SpecConstr for local bindings: seed specialisation from the calls · e5adcaf8
      simonpj@microsoft.com authored
      This patch makes a significant improvement to SpecConstr, based on
      Roman's experience with using it for stream fusion.  The main change is
        * For local (not-top-level) declarations, seed the specialisation 
          loop from the calls in the body of the 'let'.
      See Note [Local recursive groups] for discussion and example.  Top-level
      declarations are treated just as before.
      Other changes in this patch:
        * New flag -fspec-constr-count=N sets the maximum number of specialisations
          for any single function to N.  -fno-spec-constr-count removes the limit.
        * Refactoring in specLoop and friends; new algebraic data types 
          OneSpec and SpecInfo instead of the tuples that were there before
        * Be less keen to specialise on variables that are simply in scope.
            f p q = letrec g a y = ...g....  in g q p
          We probably do not want to specialise 'g' for calls with exactly
          the arguments 'q' and 'p', since we know nothing about them.
  24. 05 Mar, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Refactor OccAnal; and improve dead-code elimination · 6dc702e8
      simonpj@microsoft.com authored
      The occurrence analyer is now really rather subtle when dealing
      with recursive groups; see Note [Loop breaking and RULES] especially.
      This patch refactors this code a bit, notably 
        * Introduces a new data type Details instead of a tuple
        * More clearly breaks up a recursive group into its SCCs
      	before processing it in a separate function occAnalRec
        * As a result, does better dead-code elimination, becuause it's
         	done per SCC rather than for the whole Rec