#9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I looked at all the examples where allocations changed a significant amount. Essentially it seems to me the transformation is bad for allocations if it doesn't lead to more simplification but potentially very good if it does. There were particular situations where overloaded functions were satted as they had a normal static argument and a known dictionary argument. Normally the specialiser would be expected to deal with these but self- recursive functions are only specialised across modules if `-fspecialise- aggresively` is turned on or they are marked with an `INLINABLE` pragma. (For example `CSD`, `gg`). In situations where the definition was not further simplified, allocations tended to increase by a few %. So I'm not convinced that the example in comment:13 would be a win. There were also some situations where the unfolding for the satted definition was not exported as it was too big so there was never any potential for improvement. To sum up, there were some wins where SAT acted across modules where normal specialisation failed. Satting static function arguments could also be very good but only if there are actually some cases where the function is called with a static function argument. (For example #14211) In general though there was very little benefit satting as it seems that static values are not usually consumed by functions (and so no further simplification takes place after the sat). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9374#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler