#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