1. 16 Dec, 2014 16 commits
    • Peter Wortmann's avatar
      Tick scopes · 5fecd767
      Peter Wortmann authored
      This patch solves the scoping problem of CmmTick nodes: If we just put
      CmmTicks into blocks we have no idea what exactly they are meant to
      cover.  Here we introduce tick scopes, which allow us to create
      sub-scopes and merged scopes easily.
      
      Notes:
      
      * Given that the code often passes Cmm around "head-less", we have to
        make sure that its intended scope does not get lost. To keep the amount
        of passing-around to a minimum we define a CmmAGraphScoped type synonym
        here that just bundles the scope with a portion of Cmm to be assembled
        later.
      
      * We introduce new scopes at somewhat random places, aligning with
        getCode calls. This works surprisingly well, but we might have to
        add new scopes into the mix later on if we find things too be too
        coarse-grained.
      
      (From Phabricator D169)
      5fecd767
    • Peter Wortmann's avatar
      Source notes (Cmm support) · 7ceaf96f
      Peter Wortmann authored
      This patch adds CmmTick nodes to Cmm code. This is relatively
      straight-forward, but also not very useful, as many blocks will simply
      end up with no annotations whatosever.
      
      Notes:
      
      * We use this design over, say, putting ticks into the entry node of all
        blocks, as it seems to work better alongside existing optimisations.
        Now granted, the reason for this is that currently GHC's main Cmm
        optimisations seem to mainly reorganize and merge code, so this might
        change in the future.
      
      * We have the Cmm parser generate a few source notes as well. This is
        relatively easy to do - worst part is that it complicates the CmmParse
        implementation a bit.
      
      (From Phabricator D169)
      7ceaf96f
    • Peter Wortmann's avatar
      Strip source ticks from iface code if DWARF is disabled · a0895fcb
      Peter Wortmann authored
      They would be unneeded at minimum. Not completely sure this is the right
      place to do this.
      
      (From Phabricator D169)
      a0895fcb
    • Peter Wortmann's avatar
      Source notes (CorePrep and Stg support) · 4cdbf802
      Peter Wortmann authored
      This is basically just about continuing maintaining source notes after
      the Core stage. Unfortunately, this is more involved as it might seem,
      as there are more restrictions on where ticks are allowed to show up.
      
      Notes:
      
      * We replace the StgTick / StgSCC constructors with a unified StgTick
        that can carry any tickish.
      
      * For handling constructor or lambda applications, we generally float
        ticks out.
      
      * Note that thanks to the NonLam placement, we know that source notes
        can never appear on lambdas. This means that as long as we are
        careful to always use mkTick, we will never violate CorePrep
        invariants.
      
      * This is however not automatically true for eta expansion, which
        needs to somewhat awkwardly strip, then re-tick the expression in
        question.
      
      * Where CorePrep floats out lets, we make sure to wrap them in the
        same spirit as FloatOut.
      
      * Detecting selector thunks becomes a bit more involved, as we can run
        into ticks at multiple points.
      
      (From Phabricator D169)
      4cdbf802
    • Peter Wortmann's avatar
      Annotation linting · 07d604fa
      Peter Wortmann authored
      This adds a way by which we can make sure that the Core passes treat
      annotations right: We run them twice and compare the results.
      
      The main problem here is that Core equivalence is awkward: We do not
      want the comparison to care about the order of, say, top-level or
      recursive bindings. This is important even if GHC generally generates
      the bindings in the right order - after all, if something goes wrong
      we don't want linting to dump out the whole program as the offense.
      
      So instead we do some heuristic matching - first greedily match
      everything that's easy, then match the rest by label order. This
      should work as long as GHC generates the labels in roughly the same
      order for both pass runs.  In practice it seems to work alright.
      
      We also check that IdInfos match, as this might cause hard-to-spot
      bugs down the line (I had at least one bug because unfolding guidance
      didn't match!). We especially check unfoldings up until the point
      where it might get us into an infinite loop.
      
      (From Phabricator D169)
      07d604fa
    • Peter Wortmann's avatar
      Generalized Coverage pass to allow adding multiple types of Tickishs · 3b893f38
      Peter Wortmann authored
      This allows having, say, HPC ticks, automatic cost centres and source
      notes active at the same time. We especially take care to un-tangle the
      infrastructure involved in generating them.
      
      (From Phabricator D169)
      3b893f38
    • Peter Wortmann's avatar
      Source notes (Core support) · 993975d3
      Peter Wortmann authored
      This patch introduces "SourceNote" tickishs that link Core to the
      source code that generated it. The idea is to retain these source code
      links throughout code transformations so we can eventually relate
      object code all the way back to the original source (which we can,
      say, encode as DWARF information to allow debugging).  We generate
      these SourceNotes like other tickshs in the desugaring phase. The
      activating command line flag is "-g", consistent with the flag other
      compilers use to decide DWARF generation.
      
      Keeping ticks from getting into the way of Core transformations is
      tricky, but doable. The changes in this patch produce identical Core
      in all cases I tested -- which at this point is GHC, all libraries and
      nofib. Also note that this pass creates *lots* of tick nodes, which we
      reduce somewhat by removing duplicated and overlapping source
      ticks. This will still cause significant Tick "clumps" - a possible
      future optimization could be to make Tick carry a list of Tickishs
      instead of one at a time.
      
      (From Phabricator D169)
      993975d3
    • Joachim Breitner's avatar
    • Herbert Valerio Riedel's avatar
      Convert `/Since: .../` to new `@since ...` syntax · 554aedab
      Herbert Valerio Riedel authored
      Starting with Haddock 2.16 there's a new built-in support for since-annotations
      
      Note: This exposes a bug in the `@since` implementation (see e.g. `Data.Bits`)
      554aedab
    • Herbert Valerio Riedel's avatar
    • Joachim Breitner's avatar
      Use llvm-3.5 on Travis · 4a7489b1
      Joachim Breitner authored
      to avoid a build failure with T5681(optllvm). According to Ben Gamari,
      llvm-3.4 is known to be not working with GHC HEAD.
      4a7489b1
    • Herbert Valerio Riedel's avatar
      *Really* Re-Update Haddock submodule · 06ba9818
      Herbert Valerio Riedel authored
      The actual gitlink update got lost in 0c9c2d89
      06ba9818
    • Gabor Greif's avatar
      Typo in feature description · abd2adaa
      Gabor Greif authored
      abd2adaa
    • Herbert Valerio Riedel's avatar
      f0cf7aff
    • Herbert Valerio Riedel's avatar
    • Herbert Valerio Riedel's avatar
      493bf375
  2. 15 Dec, 2014 13 commits
  3. 14 Dec, 2014 10 commits
  4. 13 Dec, 2014 1 commit
    • Sergei Trofimovich's avatar
      Parser: remove unused rule (copy/paste error) · 288c7c6a
      Sergei Trofimovich authored
      Summary:
      Found out when tracking down conflicts reported by happy.
      It was accidentally introduced in large Api Annotations
      patch: 803fc5db
      
      Before:
        unused rules: 1
        shift/reduce conflicts:  60
        reduce/reduce conflicts: 16
      After:
        shift/reduce conflicts:  60
        reduce/reduce conflicts: 12
      
      Unused rule is seen in happy's --info= output as:
          rule 180 is unused
          ...
          decl_cls -> 'default' infixexp '::' sigtypedoc     (180)
          decl_cls -> 'default' infixexp '::' sigtypedoc     (181)
      
      While at it removed 'q' typo in parser conflict log :)
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Reviewers: simonmar, austin, alanz
      
      Reviewed By: alanz
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D569
      288c7c6a