#13160: Simplify CoreFV.FVAnn
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: bgamari
Type: task | Status: new
Priority: high | Milestone: 8.4.1
Component: Compiler | Version: 8.0.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D3170
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Simon Peyton Jones ):
In [changeset:"751996e90a964026a3f86853338f10c82db6b610/ghc" 751996e/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="751996e90a964026a3f86853338f10c82db6b610"
Kill off complications in CoreFVs
When doing type-in-type, Richard introduce some substantial
complications in CoreFVs, gathering types and free variables
of type. In Trac #13160 we decided that this complication was
unnecessary, so this patch removes it.
Unfortnately I then fell down a twisty rabbit hole. Roughly:
* An apparently-innocuous change in the AnnApp case of
fiExpr made the fuction a little bit stricter, so we ended
up peering into the arguments when we didn't before (namely
when there are no bindings being floated inwards). I've
rejigged it so that it's not fragile any more.
* Peering into the arguments was sometimes expensive, becuase
exprIsExpandable can be expensive because it looks deeply into
the expression.
* The combination of the two led to a non-linear explosion
of work when the argument of a function is a deeep nest
of constructors. This bug has been lurking for ages.
I solved it by replacing exprIsExpandable with exprIsHNF
+ exprIsTrivial; see Note [noFloatInto considerations]
* The code around floating case-expressions turned out to be
very delicate, because can_fail primops (which we want to
float inwards) can't be floated outwards; so we have to be
careful never to float them too far. Note [Floating primops]
has the details
* I ended up refactoring some rather opaque code in
sepBindsByDropPoint.
Working all this out meant that I rewrote quite a bit of
code, so it's now a reasonably substantial patch. But it's
a net improvement.
}}}
--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13160#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
