1. 06 Mar, 2006 1 commit
  2. 05 Mar, 2006 1 commit
  3. 04 Mar, 2006 12 commits
  4. 03 Mar, 2006 1 commit
  5. 09 Feb, 2006 1 commit
  6. 05 Feb, 2006 2 commits
  7. 03 Feb, 2006 1 commit
  8. 02 Mar, 2006 6 commits
  9. 01 Mar, 2006 10 commits
  10. 28 Feb, 2006 5 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.
    • 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.
    • 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.
    • 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).
    • 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
      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).