1. 14 Jul, 2006 1 commit
  2. 12 Jul, 2006 4 commits
    • simonpj@microsoft.com's avatar
      Comments and import trimming · 6bca92c3
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Experimental flag -fdicts-cheap · e1231b2b
      simonpj@microsoft.com authored
      This experimental flag, -fdicts-cheap, makes a let-binding that bind a
      value of dictionary type look cheap.  That in turn leads to more
      eta expansion.  Instead of
      	f = /\a. \(d1:Ord a). let d2:Ord [a] = dfOrd a d1 in
                       \(x:a). <stuff>
      which has arity 1, you get
      	f = /\a. \(d1:Ord a). \(x:a).
      	         let d2:Ord [a] = dfOrd a d1 in <stuff>
      Now f has arity 2.
      This can cretainly waste dictionary-construction work, if f is
      partially applied to its dictionary argument.  However it has knock-on
      effects.  Because f has arity 2, we won't float (f Int d) out of
      	\x. h (f Int d)
      Floating f out of this lambda makes it impossible for an h/f fusion
      rule to fire; and this unexpected loss of RULE application was the
      immediate reason for implementing this flag. (Roman Leshchinskiy came
      across this when working on array fusion.)
      I've implemented the change only in CoreUtils.arityType, which
      only affects eta expansion.  I thought of putting the change in
      exprIsCheap, which is a more systematic place (the former calls
      the latter) but
      	a) I wanted this under flag control, and the flags 
      	are not readily available to all callers of exprIsCheap
      	b) I'm not 100% convinced that this change is a good
      	idea, so it's reasonable to do the narrowest change
      	that solves the immediate problem.
    • Malcolm.Wallace@cs.york.ac.uk's avatar
    • Simon Marlow's avatar
  3. 06 Jul, 2006 1 commit
  4. 10 Jul, 2006 1 commit
    • Simon Marlow's avatar
      re-add -fvia-C · ab27a311
      Simon Marlow authored
      There are still some fixes required to get the threaded RTS compilable
      with the NCG, and apparently there are problems on 32-bit archs too.
  5. 24 Jun, 2006 1 commit
  6. 02 Jul, 2006 2 commits
    • Jan Rochel's avatar
      Z-Encode external-core output · 202712d3
      Jan Rochel authored
      HEAD doesn't z-encode external-core output (unlike 6.4). I suppose, that
      this is unwanted behaviour. It probably results from this patch:
      Fri Jan  6 17:30:19 CET 2006  simonmar
        * [project @ 2006-01-06 16:30:17 by simonmar]
        Add support for UTF-8 source files
      Z-encoding has been moved right to the back end.  Previously we
      used to Z-encode every identifier on the way in for simplicity,
      and only decode when we needed to show something to the user.
      Instead, we now keep every string in its UTF-8 encoding, and
      Z-encode right before printing it out.
    • Jan Rochel's avatar
      Add %local-tag to external core output · 99bab7d8
      Jan Rochel authored
      Hello, this is my first patch contributed to GHC. If there are any
      inadequacies about it (maybe like this introductory disclaimer), please
      let me know about it.
      So, the need for this patch arose, while I was involved with processing
      hcr files (external core output) and I noticed, that the output didn't
      fully conform to the specification [1].
      No %local-tags were used, which turned out to be a real nuisance as it
      was not possible to determine which VDEFs can be erased in a further
      optimization process and which ones are exported by the module.
      Since the specification does not define the meaning of the %local-tag, I
      assume, it makes sense, that it tags all functions, that are not
      exported by the module.
      The patch does not fully comply to the specification, as in my
      implementation a local tag may appear before a VDEF but not before a
      [1] An External Representation for the GHC Core Language
          (DRAFT for GHC5.02), page 3, line 1
  7. 03 Jul, 2006 1 commit
  8. 04 Jul, 2006 1 commit
  9. 03 Jul, 2006 1 commit
    • simonpj@microsoft.com's avatar
      The dict-bindings in an IPBinds need not be in dependency order · 5c9c3660
      simonpj@microsoft.com authored
      This appears to be a long-standing bug, discovered by BlueSpec 
      (ravi@bluespec.com), Trac bug #795
      The problem was that in an IP binding group, the dict bindings
      aren't necessarily in dependency order; and if they aren't 
      we get a core-lint error.
      Test tc203 checks this case.  (Though whether it shows up at
      all depends a bit on accidental factors of binding ordering.)
  10. 04 Jul, 2006 1 commit
  11. 29 Jun, 2006 11 commits
  12. 23 Jun, 2006 1 commit
  13. 20 Jun, 2006 8 commits
  14. 29 Jun, 2006 1 commit
  15. 27 Jun, 2006 3 commits
  16. 26 Jun, 2006 2 commits
    • simonpj@microsoft.com's avatar
      More SpecConstr tuning · b5f43414
      simonpj@microsoft.com authored
      For some reason, SpecConstr wasn't taking account of let-bound constructors:
      	let v = Just 4
      	in ...(f v)...
      Now it does.  An easy fix fortunately.
    • simonpj@microsoft.com's avatar
      Improve consistency checking for derived instances · 7f0ce617
      simonpj@microsoft.com authored
      This patch arranges that derived instances use the same instance-decl
      checking code as user-defined instances.  That gives greater consistency
      in error messages.
      Furthermore, the error description if this consistency check fails is now
      much more explicit.  For example, drvfail003 now says
           Variable occurs more often in a constraint than in the instance head
             in the constraint: Show (v (v a))
           (Use -fallow-undecidable-instances to permit this)
           In the derived instance
             instance (Show (v (v a))) => Show (Square_ v w a)