[GHC] #14688: Note [Lone variables] leads to missing a case-of-case opportunity

GHC ghc-devs at haskell.org
Fri Jan 19 17:15:12 UTC 2018


#14688: Note [Lone variables] leads to missing a case-of-case opportunity
-------------------------------------+-------------------------------------
        Reporter:  mpickering        |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:
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):

 Crumbs, you are right.  Looking at the `Note [Lone variables]` I see
 {{{
 Fundamentally such contexts should not encourage inlining because the
 context can ``see'' the unfolding of the variable (e.g. case or a
 RULE) so there's no gain.  If the thing is bound to a value.
 ...
    So the non-inlining of lone_variables should only apply if the
    unfolding is regarded as cheap; because that is when exprIsConApp_maybe
    looks through the unfolding.  Hence the "&& is_wf" in the
    InlineRule branch.
 }}}
 But actually `exprIsConApp_maybe` uses `expandUnfolding_maybe` to look
 through the unfolding, which in turn uses the `uf_expandable` field of the
 unfolding, not the `uf_is_work_free` field.

 Conclusion: the test in `interesting_call` in `tryUnfolding` (at `Note
 [Lone variable]`) should not test `is_wf` but rather `is_exp`.

 That's an extremely simple, local change. Can you try it?  I think it'll
 fix your problem.

 If it does, could you do a nofib comparison, before and after?  Thanks.
 This looks promising.

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


More information about the ghc-tickets mailing list