1. 18 May, 1999 7 commits
  2. 17 May, 1999 2 commits
  3. 14 May, 1999 2 commits
  4. 13 May, 1999 6 commits
  5. 12 May, 1999 1 commit
  6. 11 May, 1999 14 commits
    • keithw's avatar
      [project @ 1999-05-11 17:05:43 by keithw] · 192b2bc9
      keithw authored
      Remove some comments left in by mistake.
      192b2bc9
    • keithw's avatar
      [project @ 1999-05-11 16:49:44 by keithw] · 59555db8
      keithw authored
      Whoops, forgot to mention the following change:
      
        Various ticky counters have changed:
          - TICK_ALLOC_THK is now TICK_ALLOC_{UP,SE}_THK (updatable versus
            single-entry).
          - TICK_UPD_{NEW,OLD}_IND is now TICK_UPD_{NEW,OLD}_{,PERM_}IND.
          - UPD_{CAF_,}BH_{UPDATABLE,SINGLE_ENTRY}_ctr added, counting the
            creation of various flavours of black holes.
          - ENT_PERM_IND, UPD_{NEW,OLD}_PERM_IND are only dumped if update
            squeezing is off; see comment in Ticky.c
      
        Some documentation for ticky-ticky has been added to the user guide.
      59555db8
    • keithw's avatar
      [project @ 1999-05-11 16:47:39 by keithw] · eb407ca1
      keithw authored
      (this is number 9 of 9 commits to be applied together)
      
        Usage verification changes / ticky-ticky changes:
      
        We want to verify that SingleEntry thunks are indeed entered at most
        once.  In order to do this, -ticky / -DTICKY_TICKY turns on eager
        blackholing.  We blackhole with new blackholes: SE_BLACKHOLE and
        SE_CAF_BLACKHOLE.  We will enter one of these if we attempt to enter
        a SingleEntry thunk twice.  Note that CAFs are dealt with in by
        codeGen, and ordinary thunks by the RTS.
      
        We also want to see how many times we enter each Updatable thunk.
        To this end, we have modified -ticky.  When -ticky is on, we update
        with a permanent indirection, and arrange that when we enter a
        permanent indirection we count the entry and then convert the
        indirection to a normal indirection.  This gives us a means of
        counting the number of thunks entered again after the first entry.
        Obviously this screws up profiling, and so you can't build a ticky
        and profiling compiler any more.
      
        Also a few other changes that didn't make it into the previous 8
        commits, but form a part of this set.
      eb407ca1
    • keithw's avatar
      [project @ 1999-05-11 16:46:20 by keithw] · 29b65248
      keithw authored
      (this is number 8 of 9 commits to be applied together)
      
        The CPP flag LAZY_BLACKHOLING has been moved up from options.h into
        Stg.h, so GHC can see it as well as the interpreter, and
        EAGER_BLACKHOLING has been added.  The default is still
        LAZY_BLACKHOLING && !EAGER_BLACKHOLING.
      29b65248
    • keithw's avatar
      [project @ 1999-05-11 16:44:02 by keithw] · 5c0b6550
      keithw authored
      (this is number 7 of 9 commits to be applied together)
      
        The code generator now incorporates the update avoidance
        optimisation: a thunk of __o type is now made SingleEntry rather
        than Updatable.
      
        We want to verify that SingleEntry thunks are indeed entered at most
        once.  In order to do this, -ticky turns on eager blackholing.
        Ordinary thunks will be dealt with by the RTS, but CAFs are
        blackholed by the code generator.  We blackhole with new blackholes:
        SE_CAF_BLACKHOLE.  We will enter one of these if we attempt to enter
        a SingleEntry thunk twice.
      5c0b6550
    • keithw's avatar
      [project @ 1999-05-11 16:42:54 by keithw] · f54faab0
      keithw authored
      (this is number 6 of 9 commits to be applied together)
      
        It is useful to know the usage of a lambda outside the usage
        inference (specifically, in the simplifier); thus as a temporary
        hack to make this information available without undue modification
        to the rest of the compiler, the information is copied into the
        IdInfo field of the binder.
      
        The new information is LBVarInfo, which can be either NoLBVarInfo or
        IsOneShotLambda, corresponding to __m/no info and __o respectively.
        LBVarInfo is not intended to be printed in interface files; to
        enforce this ppLBVarInfo is defined to print nothing.
      f54faab0
    • keithw's avatar
      [project @ 1999-05-11 16:42:29 by keithw] · 1e23fb08
      keithw authored
      (this is number 5b of 9 commits to be applied together)
      
        The major purpose of this commit is to introduce usage information
        and usage analysis into the compiler, per the paper _Once Upon a
        Polymorphic Type_ (Keith Wansbrough and Simon Peyton Jones, POPL'99,
        and Glasgow TR-1998-19).
      
        An analysis is provided that annotates a Core program with optimal
        usage annotations.  This analysis is performed by -fusagesp
        (=CoreDoUSPInf), and requires -fusagesp-on (=opt_UsageSPOn).  This
        latter performs an analysis in tidyCorePgm, immediately before
        CoreToStg is done.  The driver flag -fusagesp currently provides hsc
        with -fusagesp-on, and if -O is on does a single -fusagesp early on
        in the Core-to-Core sequence.  Please change this as desired.
      
        *NB*: For now, -fusagesp with -O requires -fno-specialise.  Sorry.
      
        The flags -ddump-usagesp (=opt_D_dump_usagesp) and -dusagesp-lint
        (=opt_DoUSPLinting) (also -dnousagesp-lint to the driver) have been
        added and are documented in the User Guide.
      1e23fb08
    • keithw's avatar
      [project @ 1999-05-11 16:41:56 by keithw] · 2a34e381
      keithw authored
      (this is number 5a of 9 commits to be applied together)
      
        The major purpose of this commit is to introduce usage information
        and usage analysis into the compiler, per the paper _Once Upon a
        Polymorphic Type_ (Keith Wansbrough and Simon Peyton Jones, POPL'99,
        and Glasgow TR-1998-19).
      
        An analysis is provided that annotates a Core program with optimal
        usage annotations.  This analysis is performed by -fusagesp
        (=CoreDoUSPInf), and requires -fusagesp-on (=opt_UsageSPOn).  This
        latter performs an analysis in tidyCorePgm, immediately before
        CoreToStg is done.  The driver flag -fusagesp currently provides hsc
        with -fusagesp-on, and if -O is on does a single -fusagesp early on
        in the Core-to-Core sequence.  Please change this as desired.
      
        *NB*: For now, -fusagesp with -O requires -fno-specialise.  Sorry.
      
        The flags -ddump-usagesp (=opt_D_dump_usagesp) and -dusagesp-lint
        (=opt_DoUSPLinting) (also -dnousagesp-lint to the driver) have been
        added and are documented in the User Guide.
      2a34e381
    • keithw's avatar
      [project @ 1999-05-11 16:37:29 by keithw] · d133b73a
      keithw authored
      (this is number 4 of 9 commits to be applied together)
      
        The major purpose of this commit is to introduce usage information
        and usage analysis into the compiler, per the paper _Once Upon a
        Polymorphic Type_ (Keith Wansbrough and Simon Peyton Jones, POPL'99,
        and Glasgow TR-1998-19).
      
        Usage information has been added to types, in the form of a new kind
        of NoteTy: (UsgNote UsageAnn(UsOnce|UsMany|UsVar UVar)).  Usages
        print as __o (once), __m (many, usually omitted), or (not in
        interface files) __uvxxxx.  Usage annotations should only appear at
        certain places in a type (see the paper).  The `default' annotation
        is __m, and so an omitted annotation implies __m.  Utility functions
        for handling usage annotations are provided in Type.
      
        If the compiler is built with -DUSMANY (a flag intended for use in
        debugging by KSW only), __m are *required* and may not be omitted.
      
        The major constraint is that type arguments (eg to mkAppTy) must be
        unannotated on top.  To maintain this invariant, many functions
        required the insertion of Type.unUsgTy (removing annot from top of a
        type) or UsageSPUtils.unannotTy (removing all annotations from a
        type).  A function returning usage-annotated types for primops has
        been added to PrimOp.
      
        A new kind of Note, (TermUsg UsageAnn), has been added to annotate
        Terms.  This note is *not* printed in interface files, and for the
        present does not escape the internals of the usage inference engine.
      d133b73a
    • keithw's avatar
      [project @ 1999-05-11 16:33:35 by keithw] · f83ad713
      keithw authored
      (this is number 3 of 9 commits to be applied together)
      
        Following Haskell 98, if the module declaration is omitted it now
        defaults to "module Main(main) where", rather than the previous
        default of exporting everything.
      
        Furthermore, "module Main where" also defaults to exporting just
        Main.main rather than everything in the module (modules other than
        Main behave as normal).  This permits the usage inference to give
        better results for the Main module, since exported functions get
        worse types than nonexported functions.
      f83ad713
    • keithw's avatar
      [project @ 1999-05-11 16:33:06 by keithw] · 5c18c653
      keithw authored
      (this is number 2 of 9 commits to be applied together)
      
        Type constructors now carry information on the variance (positive
        and/or negative) of each of their type arguments (tyConArgVrcs).
        This information is provided for primitive types and computed for
        others.  If a tycon has been imported abstractly and this variance
        information is subsequently demanded, we make a pessimistic
        assumption and warn that -fno-prune-tydecls should be used.
      5c18c653
    • keithw's avatar
      [project @ 1999-05-11 16:31:33 by keithw] · 39b581ba
      keithw authored
      (this is number 1 of 9 commits to be applied together)
      
        Dictionaries now appear in interface files explicitly, rather than
        as contexts: __forall [a] => {Show a} -> ... rather than __forall
        [a] {Show a} => ... .
      39b581ba
    • sof's avatar
      [project @ 1999-05-11 14:38:47 by sof] · c9674234
      sof authored
      myThreadId doc'ed
      c9674234
    • sof's avatar
      [project @ 1999-05-11 09:15:19 by sof] · 3d2c765b
      sof authored
      couple of fixes (courtesy of MPJ)
      3d2c765b
  7. 10 May, 1999 8 commits