#13374: Let exprSize ignore case analysis -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This came out of a discussion at #1335, where Simon says:

...

So it seems that after splitting the function into two pieces, it is small enough(?) so that both pieces inline?

Yes that is galling I agree.

* Part of the trouble is that strictness analysis does a deep semantic analysis, pulls all the evals to the top, inlines them unconditionally, leaving behind a worker that may now be a lot smaller. The sizeExpr code in CoreUnfold is necessarily much simpler.

* The discount we award for a scrutinised argument is computed in size_up here:

{{{ alts_size (SizeIs tot tot_disc tot_scrut) -- Size of all alternatives (SizeIs max _ _) -- Size of biggest alternative = SizeIs tot (unitBag (v, 20 + tot - max) `unionBags` tot_disc) tot_scrut }}}

For a single-alternative case (and you have a tuple arg here) tot = max, so there's fixed discount of 20. You could make that into a controllable flag and try varying it.

* Idea. If a function starts with case x of blah (even if wrapped in lets) we know that the strictness analyser will find it strict in x. So we know it'll generate a wrapper, and the wrapper will inline. So in the end it'll be as if that case cost nothing at all. It would not be hard to make sizeExpr simply count zero for the cost of such cases; including nested. (Certainly for single-alternative ones.)

Worth a try?

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13374 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler