[GHC] #15091: Better occurrence analysis for join points

#15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this {{{ let x = ... in join j y = x+y in case v of A -> x B -> j 1 C -> j 2 D -> 3 }}} What does `OccAnal` say about `x`'s usage? It says `ManyOccs`! But it's plain as a pikestaff that `x` is used at most once: * Either in the `A` branch, * or in the `B` or `C` branches via `j`. If instead we had inlined `j` we'd have {{{ let x = ... in join j y = x+y in case v of A -> x B -> x + 1 C -> x + 2 D -> 3 }}} and now it's all more obvious: `x`'s occurrence info should be `OneOcc { occ_one_br = False }`, not `ManyOccs`. Does this matter? Not a great deal, but there is a reason for having `OneOcc` with `occ_one_br = False`, and it seems a shame not to take advantage. One case in point is the definition of `SimplUtils.isExitJoinId {{{ isExitJoinId :: Var -> Bool isExitJoinId id = isJoinId id && isOneOcc (idOccInfo id) && occ_in_lam (idOccInfo id) }}} Something does not cease to be an exit-join-point if it is mentioned in multiple places as above. Another use for this info is `postInlineUnconditionally`. Could we improve this situation? I think it'd be quite easy. For non- recursive join points `j = rhs` * Gather occurrence info from the RHS * Bind `j` to its occurrence info * Unleash that occurrence info at each jump-site for `j`, just as if it had been inlined. See Trac #14152, comment:40. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15091 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) Comment: Sounds a lot like how the demand analyser always uses LetDown to handle join points. `Note [Demand analysis for join points]` might be relevant. I found that occurrence analysis, usage analysis and call arity (to an extent) are strongly related, as they all try to compute max cardinality info. So they should agree on how to handle join points. ticket:13479#comment:10 hints about this for Call Arity. Appearently, `Note [Call Arity and Join Points]` explains we currently don't do this because of complexity concerns, probably because Call Arity has no analogue of LetDown. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15091#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by runeks): * cc: runeks (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15091#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC