[GHC] #15754: Move free variable computation to after STG passes

[GHC]

#15754: Move free variable computation to after STG passes
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  8.6.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #9718             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by osa1):

 * related:   => #9718


Comment:

 So, for #9718 I'm working on a large Stg refactoring that fixes this
 ticket
 too. I'll add the detailed refactoring plan in #9718. Basically the
 proposal is
 we do analyses as late as possible, and for free variables we do the
 analysis
 right before code generation. But if late lambda lifting uses this
 information
 then that's not going to work, we need to do it earlier, and then make
 sure
 (perhaps only in debug builds or with a flag) that late lambda lift
 correctly
 updates free variables of closures.

 Because lll (late lambda lift) will be the first pass that'll need the
 free
 variables I think we should compute it right before the pass. That means
 (depending on when we're running lll) some passes may not have the
 information.
 In that case perhaps it's better to remove the fvs list from the syntax,
 and
 pass it around in an environment.

 Alternatively we could keep it in the syntax, do the computation in
 CoreToStg,
 and run a sanity check after each pass to make sure the information
 remains
 correct. However this means that a pass that doesn't need the information,
 but
 incidentally updates it (we currently don't have such a pass) will have to
 deal
 with the fvs field. Not sure if this is a huge concern right now..

 Any thoughts?

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