1. 03 Oct, 2001 1 commit
  2. 02 Oct, 2001 2 commits
  3. 01 Oct, 2001 11 commits
  4. 28 Sep, 2001 1 commit
    • 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
  5. 27 Sep, 2001 1 commit
  6. 26 Sep, 2001 5 commits
    • 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
    • simonpj's avatar
      [project @ 2001-09-26 15:12:33 by simonpj] · e0d750be
      simonpj authored
      ------------------
      		Simon's big commit
      		------------------
      
      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!
      e0d750be
    • simonpj's avatar
      [project @ 2001-09-26 15:11:50 by simonpj] · 5cd3527d
      simonpj authored
      -------------------------------
      	Code generation and SRT hygiene
      	-------------------------------
      
      This is a big tidy up commit.  I don't think it breaks anything,
      but it certainly makes the code clearer (to me).
      
      I'm not certain that you can use it without sucking in my other
      big commit... they come from the same tree.
      
      
      Core-to-STG, live variables and Static Reference Tables (SRTs)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      I did a big tidy-up of the live-variable computation in CoreToStg.
      The key idea is that the live variables consist of two parts:
      	dynamic live vars
      	static live vars (CAFs)
      
      These two always travel round together, but they were always
      treated separately by the code until now. Now it's a new data type:
      
      type LiveInfo = (StgLiveVars, 	-- Dynamic live variables;
      				-- i.e. ones with a nested (non-top-level) binding
      		 CafSet)	-- Static live variables;
      				-- i.e. top-level variables that are CAFs or refer to them
      
      There's lots of documentation in CoreToStg.
      
      Code generation
      ~~~~~~~~~~~~~~~
      Arising from this, I found that SRT labels were stored in
      a LambdaFormInfo during code generation, whereas they *ought*
      to be in the ClosureInfo (which in turn contains a LambdaFormInfo).
      
      This led to lots of changes in ClosureInfo, and I took the opportunity
      to make it into a labelled record.
      
      Similarly, I made the data type in AbstractC a bit more explicit:
      
        -- C_SRT is what StgSyn.SRT gets translated to...
        -- we add a label for the table, and expect only the 'offset/length' form
      
      data C_SRT = NoC_SRT
      	   | C_SRT CLabel !Int{-offset-} !Int{-length-}
      
      (Previously there were bottoms lying around.)
      5cd3527d
    • simonmar's avatar
      [project @ 2001-09-26 09:41:26 by simonmar] · 2c910672
      simonmar authored
      Let's try that last commit again, and get it right this time...
      2c910672
    • simonmar's avatar
      [project @ 2001-09-26 09:16:00 by simonmar] · 6e554967
      simonmar authored
      When skipping a nested comment, keep track of the source location of
      the comment opener, so that we can report it in an error message
      rather than reporting the line at the end of the file.
      
      Also noticed a couple of ineficiencies in the nested comment code, so
      fixed those too.
      6e554967
  7. 25 Sep, 2001 1 commit
  8. 23 Sep, 2001 1 commit
    • ken's avatar
      [project @ 2001-09-23 21:29:35 by ken] · a5840900
      ken authored
      We need to pass the -w flag to gcc when compilng *_stub.c files
      in addition to when compilng *.hc files.
      
      MERGE TO STABLE
      a5840900
  9. 22 Sep, 2001 1 commit
  10. 21 Sep, 2001 1 commit
  11. 20 Sep, 2001 6 commits
    • simonpj's avatar
      [project @ 2001-09-20 16:01:23 by simonpj] · 3549fa7b
      simonpj authored
      Argh!  Bogon in last fix!  Merge to stable!
      3549fa7b
    • simonmar's avatar
      [project @ 2001-09-20 13:32:15 by simonmar] · e20d2427
      simonmar authored
      Ignore RULES pragmas when -fglasgow-exts is off.
      e20d2427
    • simonpj's avatar
      [project @ 2001-09-20 12:15:41 by simonpj] · b16004bf
      simonpj authored
      Remove dead code (no need to merge to stable branch)
      b16004bf
    • simonpj's avatar
      [project @ 2001-09-20 12:15:20 by simonpj] · 2705a8d8
      simonpj authored
      Add debug stuff (no need to merge to stable branch)
      2705a8d8
    • simonpj's avatar
      [project @ 2001-09-20 12:14:31 by simonpj] · ab061892
      simonpj authored
      ------------------------------------------------
      	Make code generation ignore isLocalId/isGlobalId
      	------------------------------------------------
      
      	MERGE WITH STABLE BRANCH
      
      CorePrep may introduce some new, top-level LocalIds.  This
      breaks an invariant that the core2stg/code generator passes
      occasionally used, namely that LocalIds are not top-level bound.
      
      This commit fixes that problem.
      
      It also removes an assert from CodeGen.cgTopRhs that asks
      for the CgInfo of such new LocalIds -- but they may (legitimately)
      not have any, so it was a bad ASSERT.  [Showed up in George
      Russel's system.]
      ab061892
    • simonpj's avatar
      [project @ 2001-09-20 08:47:13 by simonpj] · 2c250999
      simonpj authored
      ------------------------------
      	Fix a scoped-type-variable bug
      	------------------------------
      
      	MERGE WITH STABLE BRANCH
      
      The bug caused an incorrect failure when the same type
      variable was used more than once in a collection of patterns:
      
      	f (x :: t) (y :: t) = e
      
      On the way, I eliminated bindNakedTyVarsFVRn, which was only
      called once.
      2c250999
  12. 17 Sep, 2001 2 commits
  13. 14 Sep, 2001 3 commits
    • simonpj's avatar
      [project @ 2001-09-14 15:51:41 by simonpj] · 5ab261bb
      simonpj authored
      --------------------------
      	Add a rule-check pass
      	(special request by Manuel)
      	--------------------------
      
      	DO NOT merge with stable
      
      The flag
      
      	-frule-check foo
      
      will report all sites at which RULES whose name starts with "foo.."
      might apply, but in fact the arguments don't match so the rule
      doesn't apply.
      
      The pass is run right after all the core-to-core passes.  (Next thing
      to do: make the core-to-core script external, so you can fiddle with
      it.  Meanwhile, the core-to-core script is in
      	DriverState.builCoreToDo
      so you can move the CoreDoRuleCheck line around if you want.
      
      The format of the report is experimental: Manuel, feel free to fiddle
      with it.
      
      Most of the code is in specialise/Rules.lhs
      
      
      Incidental changes
      ~~~~~~~~~~~~~~~~~~
      Change BuiltinRule so that the rule name is accessible
      without actually successfully applying the rule.  This
      change affects quite a few files in a trivial way.
      5ab261bb
    • simonpj's avatar
      [project @ 2001-09-14 15:49:56 by simonpj] · 74a395c2
      simonpj authored
      -----------------
      	Make seq built in
      	-----------------
      
      	DO NOT merge with stable
      
      Until this commit 'seq' used a cunning hack so that it
      seems to be *non-strict* in its second argument:
      
        seq x y = case seq# x of { 0 -> y; other -> error "urk" }
      
      The reason for this is to make sure that x is evaluated before y,
      which is what you want in a parallel setting.
      
      But in a *sequential* settting, this simply destroys strictness
      information about y.  Now that people are starting to use seq more,
      this is becoming painful.  People sometimes use seq to make their
      function strict, and are surprised when it becomes non-strict in other
      arguments!
      
      So this commit changes seq so that it does what you would naively
      expect:
      
      	seq x y = case x of { any -> y }
      
      This is done by making seq built-in, defined along with
      	unsafeCoerce
      	getTag
      
      in MkId.lhs.  (I considered giving their unfoldings in
      PrelGHC.hi-boot.pp, but then there is the matter of making sure they
      are unfolded, since these fns don't have top-level curried defns,
      so I held off and did seq the same way as the other two.)
      
      I renamed PrelConc.seq as PrelConc.pseq; maybe its name will change
      to `then` or `before` or something else.  That's up to the GPH
      folk.
      74a395c2
    • simonpj's avatar
      [project @ 2001-09-14 15:44:13 by simonpj] · 3063cb3d
      simonpj authored
      --------------------------
      	Cleanup in DataCon
      	--------------------------
      
      	DO NOT merge with stable
      
      The dataConRepStrictness call used to reuturn a [Demand],
      but that's a bit misleading.  In particular, consider a  strict
      constructor
      
      	data Foo = MkFoo ![Int]
      
      Then the wrapper MkFoo is strict, but the worker $wMkFoo is not.
      
      	MkFoo x = case x of { DEFAULT -> $wMkFoo x }
      
      Nevertheless, when we pattern-match on $wMkFoo we will surely
      find an evaluated component to the data structure, and that is
      what dataConRepStrictness reports, and that's how it is used
      in Simplify.
      
      Solution: make dataConRepStrictness return [StrictnessMark]
      not [Demand]. A small matter really.
      3063cb3d
  14. 13 Sep, 2001 1 commit
  15. 12 Sep, 2001 2 commits
    • sewardj's avatar
      [project @ 2001-09-12 15:52:40 by sewardj] · 7a846c96
      sewardj authored
      merge (ghc-5-02-branch --> HEAD):
      
      Bugfix: there was an implicit assumption that the list of slots passed
      to freeStackSlots was already sorted, whereas in fact this wasn't the
      case for at least one call.  Now we explicitly sort the list in
      freeStackSlots, removing the hidden assumption.
      
      The symptoms of this bug include crashes (perhaps the "AsmCodeGen"
      crash), and a tendency to grow the stack a lot when let-no-escapes are
      involved (because the bug caused fragmentation of the stack free list,
      so we weren't re-using free slots properly).
        1.17.2.1  +3 -2      fptools/ghc/compiler/codeGen/CgStackery.lhs
      
      
      ASSERT that the list of stack slots we calculate in buildLivenessMask
      is sorted, because we rely on that property later.
        1.38.2.1  +5 -6      fptools/ghc/compiler/codeGen/CgBindery.lhs
      7a846c96
    • qrczak's avatar
      [project @ 2001-09-12 11:05:34 by qrczak] · 0a277a76
      qrczak authored
      Fix comment.
      0a277a76
  16. 11 Sep, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-09-11 09:02:43 by simonpj] · 630659b5
      simonpj authored
      --------------------------
      	Strictness of blockAsynch
      	--------------------------
      
      	MERGE WITH STABLE BRANCH
      
      If we're going to supply strictness info for blockAsynchExceptions#,
      it should match its arity (as other State# transformers do).
      630659b5