[GHC] #14137: Do more inlining into non-recursive join points

[GHC]

#14137: Do more inlining into non-recursive join points
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  nomeata
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      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:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 There are three threads here (maybe we need separate tickets):

 * '''The original ticket description''': this remains valid.  Did you try
 it?  It may not affect the `queens` example because of the other
 occurrences of `ds5` which I'd missed; but it's a valid and beneficial
 change regardless.

 * '''preInlineUnconditionally for join points''' (comment:7).  This ok,
 but it really should not make much difference in either direction.  Unlike
 most inlining, it doesn't eliminate an allocation; it only eliminates an
 unconditional jump; and that jump will probably be eliminated in Cmm
 anyway.  Doing the inlining cannot (I think) give rise to any knock-on
 optimisations.

   I'm intrigued why `scs` goes faster (comment:13).  Was that runtime or
 allocation?  Also in the `parsing001` benchmark, try with `-dshow-passes`
 to see if there's a change in the volume of generated code.  That's wha
 usually makes compiler perf change.

 * '''Floating out more join points'''.   I'm intrigued by your suggestion
 in comment:10, but I am not persuaded.
   * Generally speaking GHC inlines things that are called once, the exact
 reverse of ANF.  Doing is more direct and reduces clutter.
   * We'd need a way to ''stop'' these used-once join points being inlined.
   * Core has an operational interpretation, and introducing a join
 connotes an extra jump.  Maybe Cmm will eliminate it, but still.
   * Join points with parameters pass the parameters according to the
 calling convention, which we don't need.
   * Join points with parameters might be strictness analysed, specialised,
 and worker/wrappered.  All stupid for called-once join points.
   * Lastly, it doesn't solve the problem in general.  For example
 {{{
 let ys = expensive in
 letrec f xs = case xs of
                []     -> ys
                (p:ps) -> p : f ps
 in ...
 }}}
     Even after loopification `f` is not a `joinrec`.  But, if (and only
 if!) `f` is called once in `...`, it's  safe to inline `ys` in the RHS of
 `f`.  Dually, if it was
 {{{
 letrec f xs = case xs of
                []     -> expensive
                (p:ps) -> p : f ps
 in ...
 }}}
     (and `f` was called once "outside") we would not want to float
 `expensive` out.

   In short, this business of spotting the exit paths of a recursive loop
 is an interesting challenge, but it goes beyond join points.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14137#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler