[GHC] #8199: Get rid of HEAP_ALLOCED

[GHC]

#8199: Get rid of HEAP_ALLOCED
----------------------------+----------------------------------------------
        Reporter:  ezyang   |            Owner:  ezyang
            Type:  feature  |           Status:  new
  request                   |        Milestone:  7.10.1
        Priority:  normal   |          Version:  7.7
       Component:           |         Keywords:
  Compiler                  |     Architecture:  Unknown/Multiple
      Resolution:           |       Difficulty:  Project (more than a week)
Operating System:           |       Blocked By:  5435
  Unknown/Multiple          |  Related Tickets:
 Type of failure:           |
  None/Unknown              |
       Test Case:           |
        Blocking:           |
----------------------------+----------------------------------------------

Comment (by ezyang):

 I looked at the context of "The closures stored in the indirection tables
 are tagged, which means that if the code expects an untagged closure, we
 need an extra instruction to deal with it", and noticed that the only
 reason we were untagging them was because the GC functions stg_gc_enter_1
 and stg_gc_fun require 'node' to be untagged. So clearly, we should just
 have specialized versions of these functions which untag their argument.
 Actually, we can do even better: if we're making specialized versions, we
 can sidestep performing the load in code, so we have the invariant that
 for static closures, the node is a pointer to the static indirection. (Of
 course, this also means that we only get the savings from the heap checks
 of static closure entry code.) I'm implement this and see how much we
 save.

 As for overlapping the indirections with the data, there's something we
 can do even before that: since the closure that lives in memory doesn't
 have to be runnable, we can drop any fields that could be derived later.
 The counterbalance is that the initialization code gets a little more
 complex, but we're already case-splitting on the closure type, so it can't
 be too much worse. I'll also implement this and see how much better we do.

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