1. 03 Oct, 2001 1 commit
  2. 02 Oct, 2001 1 commit
  3. 01 Oct, 2001 4 commits
  4. 27 Sep, 2001 1 commit
  5. 26 Sep, 2001 1 commit
    • 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
      	    "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
      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,
      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
      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!
  6. 25 Sep, 2001 1 commit
  7. 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.
  8. 14 Sep, 2001 1 commit
    • 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
      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.
  9. 10 Sep, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-09-10 12:53:21 by simonmar] · ec2ccca2
      simonmar authored
      Remove the "extra-bin" subdirectory from $(libexecdir), since there
      are too many assumptions in the tree that $(libexecdir) == $(libdir)
      (at the moment, binary dists are fairly well broken).
      Reuben has promised to track the change in the Windows distribution.
  10. 06 Sep, 2001 2 commits
  11. 04 Sep, 2001 2 commits
    • ken's avatar
      [project @ 2001-09-04 18:29:20 by ken] · fb7a723b
      ken authored
      Please say "make -C ghc/lib/std clean; make -C hslibs clean".
      This commit eliminates spurious warning messages when compiling on
      the Alpha.  There are two kinds of spurious warning messages:
      (1) gcc: -noprefix_recognition: linker input file unused since linking not done
          This warning is because we pass the flag "-Xlinker -noprefix_recognition"
          to gcc.  We remove this warning by no longer passing the flag to gcc,
          and by removing the reason we were passing the flag in the first place:
          __init_* is now renamed to __stginit_*.
      (2) .../includes/Regs.h: warning: call-clobbered register used for global
          register variable
          This warning and all other warnings except (1), we eliminate by
          passing the -w flag to gcc.
    • sewardj's avatar
      [project @ 2001-09-04 16:35:02 by sewardj] · 10bc730f
      sewardj authored
      Build system hacks to split HSwin32.o into two parts, so that it
      can be loaded into GHCi.  Uses the same gruesome hacks as HSstd.o.
  12. 31 Aug, 2001 1 commit
  13. 30 Aug, 2001 1 commit
  14. 28 Aug, 2001 1 commit
  15. 23 Aug, 2001 3 commits
    • rrt's avatar
      [project @ 2001-08-23 12:50:13 by rrt] · b9e2f03d
      rrt authored
      On second thoughts, strip either a backslash or a slash, as if we read
      an environment variable, we may well get a slash in the path; if we
      get a result from GetTempPath, it'll probably have a backslash.
    • rrt's avatar
      [project @ 2001-08-23 12:48:54 by rrt] · 7362ac37
      rrt authored
      Strip a backslash, not a slash.
    • simonpj's avatar
      [project @ 2001-08-23 09:54:45 by simonpj] · 98bf5734
      simonpj authored
      	Be a bit more liberal when slurping instance decls
      Functional dependencies have (as usual) made things more complicated
      Suppose an interface file contains
      	interface A where
      	  class C a b | a->b where op :: a->b
      	  instance C Foo Baz where ...
      Now we are compiling
      	module B where
      	  import A
      	  t = op (v::Foo)
      Should we slurp the instance decl, even though Baz is nowhere mentioned
      in module B?  YES!  Because of the fundep, the (C Foo ?) part is enough to
      select this instance decl, and the Baz part follows.
      Rather than take fundeps into account "properly", we just slurp
      if C is visible and *any one* of the Names in the types
      This is a slightly brutal approximation, but most instance decls
      are regular H98 ones and it's perfect for them.
      	generalise the types of GatedDecl a bit
        RnHiFiles.loadInstDecl, RnHiFiles.loadRule, RnIfaces.selectGated:
      	the meat of the solution
        RdrName, OccName etc:
      	some consequential wibbles
  16. 21 Aug, 2001 5 commits
  17. 20 Aug, 2001 2 commits
  18. 19 Aug, 2001 1 commit
  19. 18 Aug, 2001 1 commit
  20. 17 Aug, 2001 4 commits
    • apt's avatar
      [project @ 2001-08-17 17:18:51 by apt] · 1dfaee31
      apt authored
      How I spent my summer vacation.
      The format of the primops.txt.pp file has been enhanced to allow
      (latex-style) primop descriptions to be included.  There is a new flag
      to genprimopcode that generates documentation including these
      descriptions. A first cut at descriptions of the more interesting
      primops has been made, and the file has been reordered a bit.
      31-bit words
      The front end now can cope with the possibility of 31-bit (or even 30-bit)
      Int# and Word# types.  The only current use of this is to generate
      external .core files that can be translated into OCAML source files
      (OCAML uses a one-bit tag to distinguish integers from pointers).
      The only way to get this right now is by hand-defining the preprocessor
      symbol WORD_SIZE_IN_BITS, which is normally set automatically from
      the familiar WORD_SIZE_IN_BYTES.
      Just in case 31-bit words are used, we now have Int32# and Word32# primitive types
      and an associated family of operators, paralleling the existing 64-bit
      stuff.  Of course, none of the operators actually need to be implemented
      in the absence of a 31-bit backend.
      There has also been some minor re-jigging of the 32 vs. 64 bit stuff.
      See the description at the top of primops.txt.pp file for more details.
      Note that, for the first time, the *type* of a primop can now depend
      on the target word size.
      Also, the family of primops intToInt8#, intToInt16#, etc.
      have been renamed narrow8Int#, narrow16Int#, etc., to emphasize
      that they work on Int#'s and don't actually convert between types.
      As another part of coping with the possibility of 31-bit ints,
      the addr2Int# and int2Addr# primops are now thoroughly deprecated
      (and not even defined in the 31-bit case) and all uses
      of them have been removed except from the (deprecated) module
      Addr# should now be treated as a proper abstract type, and has these suitable operators:
      nullAddr# : Int# -> Addr# (ignores its argument; nullary primops cause problems at various places)
      plusAddr# :  Addr# -> Int# -> Addr#
      minusAddr : Addr# -> Addr# -> Int#
      remAddr# : Addr# -> Int# -> Int#
      Obviously, these don't allow completely arbitrary offsets if 31-bit ints are
      in use, but they should do for all practical purposes.
      It is also still possible to generate an address constant, and there is a built-in rule
      that makes use of this to remove the nullAddr# calls.
      There is a new compile flag -fno-code that causes GHC to quit after generating .hi files
      and .core files (if requested) but before generating STG.
      Z-encoded names for tuples have been rationalized; e.g.,
      Z3H now means an unboxed 3-tuple, rather than an unboxed
      tuple with 3 commas (i.e., a 4-tuple)!
      Removed misc. litlits in hslibs/lang
      Misc. small changes to external core format.  The external core description
      has also been substantially updated, and incorporates the automatically-generated
      primop documentation; its in the repository at /papers/ext-core/core.tex.
      A little make-system addition to allow passing CPP options to compiler and
      library builds.
    • sof's avatar
      [project @ 2001-08-17 16:06:30 by sof] · d30f8fc1
      sof authored
      - have SysTools.FileOption take a prefix that is not to be transformed
        (this is to accommodate MS-style cmd-line options of the kind: "/out=foo.obj")
      - have users of Finder.mkHomeModuleLocn catch up with recent change to its type.
    • simonmar's avatar
      [project @ 2001-08-17 12:56:55 by simonmar] · 7f12c16a
      simonmar authored
      The .hi file wasn't tracking the module name (my fault).  Fix it.
    • sewardj's avatar
      [project @ 2001-08-17 12:43:24 by sewardj] · 0e3ae44d
      sewardj authored
      On 4.08.X compilers, just make rawSystem be System.system.  This is
      so we can still build stage1s with 4.08.X.  It won't work on Win32
      but the minimum compiler to build a stage1 for Win32 is 5.01 AFAICS.
  21. 16 Aug, 2001 3 commits
  22. 15 Aug, 2001 2 commits