[GHC] #11222: Teach strictness analysis about `catch`-like operations

GHC ghc-devs at haskell.org
Tue Dec 15 21:22:41 UTC 2015


#11222: Teach strictness analysis about `catch`-like operations
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.10.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"28638dfe79e915f33d75a1b22c5adce9e2b62b97/ghc" 28638df/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="28638dfe79e915f33d75a1b22c5adce9e2b62b97"
 primops: Mark actions evaluated by `catch*` as lazy

 There is something very peculiar about the `catch` family of operations
 with respect to strictness analysis: they turn divergence into
 non-divergence. For this reason, it isn't safe to mark them as strict in
 the expression whose exceptions they are catching. The reason is this:

 Consider,

     let r = \st -> raiseIO# blah st
     in catch (\st -> ...(r st)..) handler st

 If we give the first argument of catch a strict signature, we'll get a
 demand 'C(S)' for 'r'; that is, 'r' is definitely called with one
 argument, which indeed it is. The trouble comes when we feed 'C(S)' into
 'r's RHS as the demand of the body as this will lead us to conclude that
 the whole 'let' will diverge; clearly this isn't right.

 This is essentially the problem in #10712, which arose when
 7c0fff41789669450b02dc1db7f5d7babba5dee6 marked the `catch*` primops as
 being strict in the thing to be evaluated. Here I've partially reverted
 this commit, again marking the first argument of these primops as lazy.

 Fixes #10712.

 Test Plan: Validate checking `exceptionsrun001`

 Reviewers: simonpj, austin

 Subscribers: thomie

 Differential Revision: https://phabricator.haskell.org/D1616

 GHC Trac Issues: #10712, #11222
 }}}

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


More information about the ghc-tickets mailing list