#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