#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