[GHC] #9718: Avoid TidyPgm predicting what CorePrep will do

GHC ghc-devs at haskell.org
Fri Oct 12 08:52:04 UTC 2018


#9718: Avoid TidyPgm predicting what CorePrep will do
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.8.3
      Resolution:                    |             Keywords:  CodeGen, CAFs
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 >  Alternatively I think we could pass an environment of updated ids to
 topStgBindHasCafRefs and friends.

 Yes, let's do something more like that.

 But I have forgotten how SRTs are constructed.  We clearly need two
 passes:

 1. Find out which top-level bindings are CAFFy: that is, refers
 (transitively) to a CAF.  That simply involves a free-variable analysis
 and a fixpoint calculation.

 2. Build an SRT for each closure that lists the CAFFy things it mentions.
 It's not obvious where that is done today -- can you point to it?

 For step (2) it occurs to me that we could decorate the `StgRhsClosure`
 with the list of things to put in its SRT, just as we decorate it with the
 list of locally-bound free variables to put in its closure. That seems so
 obvious, I'm not sure why we don't do that.

 One other thought. Suppose we have
 {{{
 x = factorial 200
 p = (x,True)
 q = (False,x)
 wubble = \x. (p,q)
 }}}
 Then `x`, `y` and `p` are all CAFFy, so currently `wurble`'s SRT will
 contain both `p` and `q`.  But actually we need only one of them, because
 the goal is solely to keep `x` alive.  So actually `wurble`'s SRT could
 list `p` alone, or `q` alone, or indeed just `x`.  I'm not sure if this is
 worth exploiting; and doing so cross-module would mean we had to put more
 stuff in .hi files.

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


More information about the ghc-tickets mailing list