1. 04 Mar, 2006 6 commits
    • David Himmelstrup's avatar
      Remove the old HscMain code. · e5ea30e6
      David Himmelstrup authored
      e5ea30e6
    • David Himmelstrup's avatar
      2403cadc
    • David Himmelstrup's avatar
      Export the new HscMain API. · 19ba41d6
      David Himmelstrup authored
      19ba41d6
    • David Himmelstrup's avatar
      22930733
    • David Himmelstrup's avatar
      Description of the new HscMain. · 241eb302
      David Himmelstrup authored
      241eb302
    • David Himmelstrup's avatar
      Initial hack on the new low-level compiler API. · 3abbe090
      David Himmelstrup authored
      None of the new code is in use yet.
      
      The current Haskell compiler (HscMain.hscMain) isn't as typed
      and as hack-free as we'd like. Here's a list of the things it
      does wrong:
        * In one shot mode, it returns the new interface as _|_,
          when recompilation isn't required. It's then up to the
          users of hscMain to keep their hands off the result.
        * (Maybe ModIface) is passed around when it's known that it's
          a Just. Hey, we got a type-system, let's use it.
        * In one shot mode, the backend is returning _|_ for the
          new interface. This is done to prevent space leaks since
          we know that the result of a one shot compilation is never
          used. Again, it's up to the users of hscMain to keep their
          hands off the result.
        * It is allowed to compile a hs-boot file to bytecode even
          though that doesn't make sense (it always returns
          Nothing::Maybe CompiledByteCode).
        * Logic and grunt work is completely mixed. The frontend
          and backend keeps checking what kind of input they're handling.
          This makes it very hard to get an idea of what the functions
          actually do.
        * Extra work is performed when using a null code generator.
      
      
      The new code refactors out the frontends (Haskell, Core), the
      backends (Haskell, boot) and the code generators (one-shot, make,
      nothing, interactive) and allows them to be combined in typesafe ways.
      A one-shot compilation doesn't return new interfaces at all so we
      don't need the _|_ space-leak hack. In 'make' mode (when not
      targeting bytecode) the result doesn't contain
      Nothing::Maybe CompiledByteCode. In interactive mode, the result
      is always a CompiledByteCode. The code gens are completely separate
      so compiling to Nothing doesn't perform any extra work.
      
      DriverPipeline needs a bit of work before it can use the new
      API.
      
      3abbe090
  2. 03 Mar, 2006 1 commit
  3. 09 Feb, 2006 1 commit
  4. 05 Feb, 2006 2 commits
  5. 03 Feb, 2006 1 commit
  6. 02 Mar, 2006 6 commits
  7. 01 Mar, 2006 10 commits
  8. 28 Feb, 2006 8 commits
    • Simon Marlow's avatar
      takeMVar/putMVar were missing some write barriers when modifying a TSO · 080c9600
      Simon Marlow authored
      This relates to the recent introduction of clean/dirty TSOs, and the
      consqeuent write barriers required.  We were missing some write
      barriers in the takeMVar/putMVar family of primops, when performing
      the take/put directly on another TSO.
      
      Fixes #705, and probably some test failures.
      080c9600
    • Simon Marlow's avatar
      A better x86_64 register mapping, with more argument registers. · cd0bb88b
      Simon Marlow authored
      Now that we can handle using C argument registers as global registers,
      extend the x86_64 register mapping.  We now have 5 integer argument
      registers, 4 float, and 2 double (all caller-saves).  This results in a
      reasonable speedup on x86_64.
      cd0bb88b
    • Simon Marlow's avatar
      filter the messages generated by gcc · 98344985
      Simon Marlow authored
      Eliminate things like "warning: call-clobbered register used as global
      register variable", which is an non-suppressible warning from gcc.
      98344985
    • Simon Marlow's avatar
      Allow C argument regs to be used as global regs (R1, R2, etc.) · 14a5c62a
      Simon Marlow authored
      The problem here was that we generated C calls with expressions
      involving R1 etc. as parameters.  When some of the R registers are
      also C argument registers, both GCC and the native code generator
      generate incorrect code.  The hacky workaround is to assign
      problematic arguments to temporaries first; fortunately this works
      with both GCC and the NCG, but we have to be careful not to undo this
      with later optimisations (see changes to CmmOpt).
      14a5c62a
    • Simon Marlow's avatar
      pass arguments to unknown function calls in registers · 04db0e9f
      Simon Marlow authored
      We now have more stg_ap entry points: stg_ap_*_fast, which take
      arguments in registers according to the platform calling convention.
      This is faster if the function being called is evaluated and has the
      right arity, which is the common case (see the eval/apply paper for
      measurements).  
      
      We still need the stg_ap_*_info entry points for stack-based
      application, such as an overflows when a function is applied to too
      many argumnets.  The stg_ap_*_fast functions actually just check for
      an evaluated function, and if they don't find one, push the args on
      the stack and invoke stg_ap_*_info.  (this might be slightly slower in
      some cases, but not the common case).
      04db0e9f
    • Simon Marlow's avatar
      fix live register annotations on foreign calls · 174c7f29
      Simon Marlow authored
      fix one incorrect case, and made several more accurate
      174c7f29
    • simonpj@microsoft.com's avatar
      Simplify the IdInfo before any RHSs · 2317c27b
      simonpj@microsoft.com authored
      	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Simplfy (i.e. substitute) the IdInfo of a recursive group of Ids
      before looking at the RHSs of *any* of them.  That way, the rules
      are available throughout the letrec, which means we don't have to
      be careful about function to put first.
      
      Before, we just simplified the IdInfo of f before looking at f's RHS,
      but that's not so good when f and g both have RULES, and both rules
      mention the other.
      
      This change makes things simpler, but shouldn't change performance.
      2317c27b
    • simonpj@microsoft.com's avatar
      badd5d76
  9. 27 Feb, 2006 2 commits
  10. 22 Feb, 2006 2 commits
  11. 27 Feb, 2006 1 commit