1. 03 Oct, 2001 8 commits
    • simonpj's avatar
      [project @ 2001-10-03 13:58:13 by simonpj] · 4a1e12a1
      simonpj authored
      ----------------------------------------------
      	Output curried functions for data constructors
      	----------------------------------------------
      			(incomplete)
      
      The idea here is to output code for the *curried* version of
      the worker of a data constructor, so that the worker can be
      treated as a first-class citizen elsewhere in the compiler.
      In particular, it doesn't need to be a "hasNoBinding" thing,
      which are the subject of a number of nasty hacks.
      
      These changes only do the business for the code gen route
      via AbstractC.  Remaining to do: the byte code generator.
      
      Idea: move the byte-code gen to STG code, and inject the
      curried data-constructor workers at the STG stage.
      
      
      	I hope the changes here won't make
      	anything stop working.  For now, constructor
      	workers remain "hasNoBinding" things.
      
      CgConTbls, CodeGen, CoreTidy, CoreToStg
      4a1e12a1
    • simonmar's avatar
      [project @ 2001-10-03 13:57:42 by simonmar] · b4623557
      simonmar authored
      Tidy up ghc/includes/Constants and related things.
      
      Now all the constants that the compiler needs to know, such as header
      size, update frame size, info table size and so on are generated
      automatically into a header file, DeriviedConstants.h, by a small C
      program in the same way as NativeDefs.h.  The C code in the RTS is
      expected to use sizeof() directly (it already does).
      
      Also tidied up the constants in MachDeps.h - all the constants
      representing the sizes of various types are named SIZEOF_<foo>, to
      match the constants defined in config.h.  PrelStorable.lhs now doesn't
      contain any special knowledge about GHC's conventions as regards the
      size of certain types, this is all in MachDeps.h.
      b4623557
    • simonpj's avatar
      [project @ 2001-10-03 13:57:33 by simonpj] · e205a0ce
      simonpj authored
      -------------------------------------------
      	Don't bomb out on inlining big constructors
      	-------------------------------------------
      
      The unfolder bombs out if the expression get too big; no point in
      computing its exact size when it's vast.  But for *constructors*
      applied to a lot of args, it's worth keeping going, because we
      get a big *disount* too
      	$fFooInt = :CFoo a1 a2 a3 ... a50
      
      We want to keep the inlining for $fFooInt in interface files, so
      that importing guys can do the selection.
      
      
      Solution: only bomb out when size-discount gets too big.
      e205a0ce
    • rrt's avatar
      [project @ 2001-10-03 10:18:31 by rrt] · 5e1f86a7
      rrt authored
      This file shouldn't be in the repository any more (there's a
      PrelGHC.hi-boot.pp).
      
      Why is it only me that notices these phantom leftovers? Why don't they cause
      problems for other people?
      5e1f86a7
    • sewardj's avatar
      [project @ 2001-10-03 09:56:18 by sewardj] · 7693d3bd
      sewardj authored
      In the interactive FFI, handle f-i'd fns which return char.
      7693d3bd
    • rrt's avatar
      [project @ 2001-10-03 09:43:11 by rrt] · a3ccd83f
      rrt authored
      Remove import of unDosifyPath, and the comment saying that it is used.
      a3ccd83f
    • simonmar's avatar
      [project @ 2001-10-03 09:20:20 by simonmar] · 28274f6a
      simonmar authored
      minor wibble: use Maybe.isJust rather than maybeToBool
      28274f6a
    • simonmar's avatar
      [project @ 2001-10-03 08:16:49 by simonmar] · 2e9f2703
      simonmar authored
      Don't print the "compilation IS NOT required" in quiet mode (-v0).
      2e9f2703
  2. 02 Oct, 2001 5 commits
  3. 01 Oct, 2001 19 commits
  4. 28 Sep, 2001 3 commits
    • sof's avatar
      [project @ 2001-09-28 23:41:00 by sof] · 0f3a6bb6
      sof authored
      Rename 'doDiscard' to 'lexPragma', and make it EOF-resistant.
      As was, it would run off the end of a StringBuffer (and SIGSEGV,
      most likely) if a pragma wasn't properly closed.
      0f3a6bb6
    • sof's avatar
      [project @ 2001-09-28 23:36:50 by sof] · 53ededd0
      sof authored
      Provide finer-grained control for turning off mk/target.mk's
      'all', 'boot' and 'install' rules. i.e., instead of having
      the variable NO_ALL_TARGETS control the defnition of rules
      for all three, NO_ALL_TARGET, NO_BOOT_TARGET, and NO_INSTALL_TARGET
      lets you individually control which ones you don't want.
      
      Sub-projects (GC and HDirect, for example) have the need
      to turn off the 'boot' rule, which is what motivated this
      change.
      53ededd0
    • rrt's avatar
      [project @ 2001-09-28 10:59:50 by rrt] · ba36feb6
      rrt authored
      Tweaks to the 5.02 InstallShield to improve presentation and the range of
      help files available.
      ba36feb6
  5. 27 Sep, 2001 2 commits
  6. 26 Sep, 2001 3 commits
    • simonpj's avatar
      [project @ 2001-09-26 16:27:04 by simonpj] · 575853e3
      simonpj authored
      Wibble
      575853e3
    • simonpj's avatar
      [project @ 2001-09-26 16:22:04 by simonpj] · 1b2bd7df
      simonpj authored
      Specialise reduce
      1b2bd7df
    • simonpj's avatar
      [project @ 2001-09-26 16:19:28 by simonpj] · 6858f7c1
      simonpj authored
      ------------------
      		Simon's big commit
      		------------------
      	[ These files seem to have been left out for some reason ]
      
      
      This commit, which I don't think I can sensibly do piecemeal, consists
      of the things I've been doing recently, mainly directed at making
      Manuel, George, and Marcin happier with RULES.
      
      
      Reogranise the simplifier
      ~~~~~~~~~~~~~~~~~~~~~~~~~
      1. The simplifier's environment is now an explicit parameter.  This
      makes it a bit easier to figure out where it is going.
      
      2. Constructor arguments can now be arbitrary expressions, except
      when the application is the RHS of a let(rec).  This makes it much
      easier to match rules like
      
      	RULES
      	    "foo"  f (h x, g y) = f' x y
      
      In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
      constructor application where necessary.  In the occurrence analyser,
      there's a new piece of context info (OccEncl) to say whether a
      constructor app is in a place where it should be in ANF.  (Unless
      it knows this it'll give occurrence info which will inline the
      argument back into the constructor app.)
      
      3. I'm experimenting with doing the "float-past big lambda" transformation
      in the full laziness pass, rather than mixed in with the simplifier (was
      tryRhsTyLam).
      
      4.  Arrange that
      	case (coerce (S,T) (x,y)) of ...
      will simplify.  Previous it didn't.
      A local change to CoreUtils.exprIsConApp_maybe.
      
      5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
      error function in one branch.
      
      
      Phase numbers, RULES, and INLINE pragmas
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1.  Phase numbers decrease from N towards zero (instead of increasing).
      This makes it easier to add new earlier phases, which is what users want
      to do.
      
      2.  RULES get their own phase number, N, and are disabled in phases before N.
      
      e.g. 	{-# RULES "foo" [2] forall x y.  f (x,y) = f' x y #-}
      
      Note the [2], which says "only active in phase 2 and later".
      
      3.  INLINE and NOINLINE pragmas have a phase number to.  This is now treated
      in just the same way as the phase number on RULE; that is, the Id is not inlined
      in phases earlier than N.  In phase N and later the Id *may* be inlined, and
      here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
      as soon as it *may* be inlined it probably *will* be inlined.
      
      The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
      like the RULES case (i.e. in square brackets).  This should also make sure
      you examine all such phase numbers; many will need to change now the numbering
      is reversed.
      
      Inlining Ids is no longer affected at all by whether the Id appears on the
      LHS of a rule.  Now it's up to the programmer to put a suitable INLINE/NOINLINE
      pragma to stop it being inlined too early.
      
      
      Implementation notes:
      
      *  A new data type, BasicTypes.Activation says when a rule or inline pragma
      is active.   Functions isAlwaysActive, isNeverActive, isActive, do the
      obvious thing (all in BasicTypes).
      
      * Slight change in the SimplifierSwitch data type, which led to a lot of
      simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.
      
      * The InlinePragma in the IdInfo of an Id is now simply an Activation saying
      when the Id can be inlined.  (It used to be a rather bizarre pair of a
      Bool and a (Maybe Phase), so this is much much easier to understand.)
      
      * The simplifier has a "mode" environment switch, replacing the old
      black list.  Unfortunately the data type decl has to be in
      CmdLineOpts, because it's an argument to the CoreDoSimplify switch
      
          data SimplifierMode = SimplGently | SimplPhase Int
      
      Here "gently" means "no rules, no inlining".   All the crucial
      inlining decisions are now collected together in SimplMonad
      (preInlineUnconditionally, postInlineUnconditionally, activeInline,
      activeRule).
      
      
      Specialisation
      ~~~~~~~~~~~~~~
      1.  Only dictionary *functions* are made INLINE, not dictionaries that
      have no parameters.  (This inline-dictionary-function thing is Marcin's
      idea and I'm still not sure whether it's a good idea.  But it's definitely
      a Bad Idea when there are no arguments.)
      
      2.  Be prepared to specialise an INLINE function: an easy fix in
      Specialise.lhs
      
      But there is still a problem, which is that the INLINE wins
      at the call site, so we don't use the specialised version anyway.
      I'm still unsure whether it makes sense to SPECIALISE something
      you want to INLINE.
      
      
      
      
      
      Random smaller things
      ~~~~~~~~~~~~~~~~~~~~~~
      
      * builtinRules (there was only one, but may be more) in PrelRules are now
        incorporated.   They were being ignored before...
      
      * OrdList.foldOL -->  OrdList.foldrOL, OrdList.foldlOL
      
      * Some tidying up of the tidyOpenTyVar, tidyTyVar functions.  I've
        forgotten exactly what!
      6858f7c1