Re: [GHC] #13479: Core Lint issues during slowtest

6 Apr 2017

      #13479: Core Lint issues during slowtest
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:  JoinPoints
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10181            |  Differential Rev(s):  Phab:D3390
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by simonpj):

 * keywords:   => JoinPoints
 * status:  closed => new
 * resolution:  fixed =>
 * owner:  nomeata => (none)

Comment:

 Joachim, I think a better fix would be not to attach call-arity info to
 `JoinIds` at all, rather than to involve the simplifier.

 Consider this:
 {{{
    let g = \y. h y True
    in g 3 7
 }}}
 Ignore the fact that `g` will be inlined; I'm just keeping it simple.
 What will Call Arity say about `h`?  It'll say that `h` is definitely
 called with ''three'' arguments, right?  Becuase `g` is called with two
 arguemts, one is eaten by the `\y`, so `h` gets three.

 But suppose instead it was
 {{{
    let g = \y. join j v = h y v
                in case y of
                   True  -> j False
                   False -> j True
    in g 3 7
 }}}
 Now, we ''could'' analyse this by treating `j` like a normal function, and
 compute its join arity.  That's what we do now.  But it's simpler and more
 direct simply to propagate the "apply to 1 arg" info that we apply to the
 body of `g` directly into the RHS of `j`.  Completely ignore the
 occurrences of `j`, don't compute their join arity.

 Roughly:
 {{{
 callArityAnal arity int (Let (NonRec join_id rhs) let_body)
   | Just join_arity <- isJoinId_maybe join_id
   = ( ae_join_body `lubRes` ae_let_body
     , Let (NonRec join_id (mkLams join_bndrs join_body') let_body') )
   where
     (join_bndrs, join_body) = collectNBinders join_arity rhs
     (ae_join_body, join_body') = callArityAnal arity int join_body
     (ae_let_body,  let_body')  = callArityAnal arity int let_body
 }}}
 Now that is pretty simple!  (Something similar for `Rec`.)  In effect, we
 are pushing the evaluation context into the join RHS, just as described in
 the paper.

 I agree that this is extra code... the existing code is still needed.  But
 I think it's possible that it might give beter results in the recursive
 case.  And it's more efficient.  And it doesn't bogusly compute a call-
 arity for a join point.

 Worth considering?  I'll re-open for you to consider it.

 Simon

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13479#comment:10
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler