[GHC] #12995: interpetBCO doesn't get stripped from executables
#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
#12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint 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 osa1): I have another idea. I think we can't start a GHCi process just by using `base` from a Haskell program, right? So that part of the scheduler can only be run in `ghc-stage2`. Why not just `ifdef` those parts so that that block in the scheduler and `interpretBCO` would be defined only when compiling RTS for `ghc-stage2`? Would that be too much extra compilation? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12995#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint 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 olsner): That does sound simpler, but I believe `ghc-stage2` currently links against the same RTS libraries that are being installed? Then we'd need to introduce separate copies of the RTS for ghc itself and user programs. WRT compilation time, the RTS build at least parallelizes perfectly so that shouldn't be too bad, but it could be a bit of a build-system mess. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12995#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint 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 rwbarton): We could add a new "dimension of RTS way" (like threaded, profiling and debug) for whether or not to include the interpreter. Note that this doesn't affect just ghc itself but also programs that use the ghc library. The burden on the end user to select the correct RTS flavor doesn't seem worthwhile if the only purpose is to generate a smaller executable. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12995#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint 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 simonmar): The proposed solution in the ticket doesn't work out easily, I think, because the reference to `interpretBCO` would move from the scheduler to the entry code for BCO. So the BCO code needs to move into a separate file. Maybe things can be unravelled sufficiently, or maybe they get too tangled, I'm not sure. Adding another RTS way dimension seems too heavyweight a solution for this problem. Speaking of which, how much do we really care about this? How many Kb would be saved in a static executable? My guess is that there might be lower-hanging fruit. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12995#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint 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 olsner): Since the RTS is built with `-ffunction-sections` now, the code doesn't need to be moved to separate files. It should be enough to remove the function(s) from the call graph. But that in itself might be hard enough :) BCO-related code pops up in quite a few places - e.g. `stg_AP_*` checks the function type and invokes `stg_yield_to_interpreter` for the `ARG_BCO` case, so that would still keep the interpreter alive. The generated apply code from genapply also has calls directly to `stg_BCO` which just yields to the interpreter. `interpretBCO` is quite little code itself though, commenting out the call in `schedule` saved about 15kB. Not enough to motivate much effort at all really... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12995#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC