[GHC] #12995: interpetBCO doesn't get stripped from executables

[GHC]

#12995: interpetBCO doesn't get stripped from executables
-------------------------------------+-------------------------------------
           Reporter:  olsner         |             Owner:
               Type:  task           |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Runtime        |           Version:  8.0.1
  System                             |
           Keywords:  footprint      |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Looking at the symbols linked into a simple Hello world program (e.g. with
 `nm -S --size-sort hello_world`), interpretBCO from the RTS is one of the
 larger functions. Unless I'm missing something, a compiled program
 shouldn't need the bytecode interpreter.

 The reason it gets linked and not dead-code stripped is that the scheduler
 has a hardcoded reference to it in `case ThreadInterpret:`, and figuring
 out if that particular what_next value is possible is out of reach of the
 linker.

 I'm thinking the ThreadInterpret state could be removed, and replaced with
 a more generic "resume by calling C function" state, with a function
 pointer on the stack. Paths that enter this state would push a function
 pointer to interpretBCO, and so the linker will link against interpretBCO
 iff it's actually used.

 Or perhaps it would be possible to have the interpreter entry point follow
 STG calling conventions and use ThreadRunGHC?

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