[GHC] #13160: Simplify CoreFV.FVAnn

[GHC]

#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 <simonpj@…>):

 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