1. 22 May, 2006 5 commits
    • simonpj@microsoft.com's avatar
      Prune imports · 1375c0a7
      simonpj@microsoft.com authored
      1375c0a7
    • simonpj@microsoft.com's avatar
      Add deShadowBinds · 2c969ecc
      simonpj@microsoft.com authored
      Add CoreSubst.deShadowBinds, which removes shadowing from 
      a Core term.  I thought we wanted it for SpecConstr, but in 
      fact decided not to use it. Nevertheless, it's a useful sort
      of function to have around, and it has a particularly simple
      definition!
      2c969ecc
    • simonpj@microsoft.com's avatar
      Inline in a call argument if the caller has RULES · a2c92ccc
      simonpj@microsoft.com authored
      This is an experimental change suggested by Roman.  Consider
      	
      	{-# INLINE f #-}
      	f x y = ...
      
      	....(g (f a b))...
      
      where g has RULES.  Then we'd like to inline f, even though the context of
      the call is otherwise 100% boring -- g is lazy and we know nothing about
      x and y. 
      
      This patch just records in the continuation that f has rules.  And does so
      somewhat recursively...e.g.
      
      	...(g (h (f a b)))...
      
      where g has rules.  
      
      a2c92ccc
    • simonpj@microsoft.com's avatar
      Add idHasRules · b7d8dffa
      simonpj@microsoft.com authored
      Add Id.idHasRules :: Id -> Bool, with the obvious semantics.
      This patch makes sense by itself, but it's just a tidy-up.
      
      b7d8dffa
    • simonpj@microsoft.com's avatar
      Transmit inline pragmas faithfully · 39dd1943
      simonpj@microsoft.com authored
      *** WARNING: you will need to recompile your libraries 
      ***	     when you pull this patch (make clean; make)
      
      The inline pragma on wrapper-functions was being lost; this patch 
      makes it be transmitted faithfully.
      
      The reason is that we don't write the full inlining for a wrapper into
      an interface file, because it's generated algorithmically from its strictness
      info.  But previously the inline pragma as being written out only when we
      wrote out an unfolding, and hence it was lost for a wrapper.
      
      This makes a particular difference when a function has a NOINLINE[k] pragma.
      Then it may be w/w'd, and we must retain the pragma.  It's the only consistent
      thing to do really.
      
      The change does change the binary format of interface files, slightly.
      So you need to recompile all your libraries.
      39dd1943
  2. 19 May, 2006 3 commits
    • simonpj@microsoft.com's avatar
      Improved RULE lhs typechecking; less dictionary sharing · 5a8a219c
      simonpj@microsoft.com authored
      See long comment with Simplify.tcSimplifyRuleLhs.
      
      Here's the key example:
      
        RULE "g"  forall x y z. g (x == y) (y == z) = ...
      
      Here, the two dictionaries are *identical*, but we do NOT WANT to
      generate the rule
      
      RULE	forall x::a, y::a, z::a, d1::Eq a
      	  f ((==) d1 x y) ((>) d1 y z) = ...
      
      Instead we want
      
      RULE	forall x::a, y::a, z::a, d1::Eq a, d2:Eq a
      	  f ((==) d1 x y) ((>) d2 y z) = ...
      5a8a219c
    • simonpj@microsoft.com's avatar
      Bug-fix for infix function definitions (parse/rename) · cbc86d74
      simonpj@microsoft.com authored
        
      Fix a crash provoked by
      
      	x `op` y = x
      	op       = True
      
      The trouble was that there is currently a single 'infix' flag for the
      whole group; and RnTypes.checkPrecMatch was therefore expecting the
      second eqn to have two args.
      
      This fixes the crash, and also or-s the infix flags for the various
      eqns together; previously it was just taken from the first eqn, which
      was wrong.
      
      cbc86d74
    • simonpj@microsoft.com's avatar
      Remove misleading comments · c2a3f586
      simonpj@microsoft.com authored
      c2a3f586
  3. 18 May, 2006 9 commits
  4. 17 May, 2006 8 commits
  5. 16 May, 2006 1 commit
    • duncan.coutts@worc.ox.ac.uk's avatar
      Let GHCi work with with Sparc32+/V8+ .o files · 82807c21
      duncan.coutts@worc.ox.ac.uk authored
      Currently the GHCi linker looks exclusively for V7 ABI .o files.
      
      You can generate V8+ ABI .o files using flags to gcc such as:
       -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
      
      Note that this allows gcc to generate hardware integer division and
      hardware floating point instructions rather than using software emulation.
      All recent sparc hardware is V8+ or later. Perhaps we should check for the
      cpu generation in configure and use the later ABI if possible.
      
      Tested briefly on a SunBlade 100 (TI UltraSparc IIe) sparc-unknown-linux
      82807c21
  6. 15 May, 2006 1 commit
  7. 10 May, 2006 5 commits
  8. 09 May, 2006 2 commits
  9. 08 May, 2006 5 commits
    • simonpj@microsoft.com's avatar
      Do not put wired-in things in interface files · ef61cbbc
      simonpj@microsoft.com authored
      There is no need for wired-in things to go into interface files; the compiler
      knows about them anyway.  Worse, it turns ou that if they are in an interface
      file, they may get read in with not-quite-right type info (e.g. GHC.Err.error),
      and the not-quite-right thing gets into the type envt.  Than it gets used 
      instead of the wired in thing.
      
      Best all round never to put them into interface files.  This is the way
      it used to be, but it looks as if it rotted away some time ago.
      
      (I noticed this when fixing unsafePerformIO stuff, becuase 'lazy' was getting
      an unfolding when it shouldn't.)
      ef61cbbc
    • simonpj@microsoft.com's avatar
      Remove NOINLINE strictness hack · 302265d5
      simonpj@microsoft.com authored
      The stricteness analyser used to have a HACK which ensured that NOINLNE things
      were not strictness-analysed.  The reason was unsafePerformIO. Left to itself,
      the strictness analyser would discover this strictness for unsafePerformIO:
      	unsafePerformIO:  C(U(AV))
      But then consider this sub-expression
      	unsafePerformIO (\s -> let r = f x in 
      			       case writeIORef v r s of (# s1, _ #) ->
      			       (# s1, r #)
      The strictness analyser will now find that r is sure to be eval'd,
      and may then hoist it out.  This makes tests/lib/should_run/memo002
      deadlock.
      
      Solving this by making all NOINLINE things have no strictness info is overkill.
      In particular, it's overkill for runST, which is perfectly respectable.
      Consider
      	f x = runST (return x)
      This should be strict in x.
      
      So the new plan is to define unsafePerformIO using the 'lazy' combinator:
      
      	unsafePerformIO (IO m) = lazy (case m realWorld# of (# _, r #) -> r)
      
      Remember, 'lazy' is a wired-in identity-function Id, of type a->a, which is 
      magically NON-STRICT, and is inlined after strictness analysis.  So
      unsafePerformIO will look non-strict, and that's what we want.
      
      Now we don't need the hack in the strictness analyser.
      302265d5
    • simonpj@microsoft.com's avatar
      Trim imports · 36b27193
      simonpj@microsoft.com authored
      36b27193
    • simonpj@microsoft.com's avatar
      Trim imports · bbf41467
      simonpj@microsoft.com authored
      bbf41467
    • Simon Marlow's avatar
      GHC_MANGLER-->MANGLER · 02de51da
      Simon Marlow authored
      02de51da
  10. 05 May, 2006 1 commit