
#13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I discussed this on IRC with David briefly. {{{ mpickering> dfeuer: I don't think SPECIALISE INLINE ever worked like you are suggesting. I think it just works like SPECIALISE and then marks the specialisation with an INLINE pragma 10:07 PM <mpickering> I was under the impression that SpecConstr allowed you to force this unrolling to happen 10:08 PM <mpickering> The manual states that "and applies even if the function is recursive." 10:09 PM <mpickering> but I don't know what this means or how it works as there is no special check in the simplifier to inline specialisations arising from SPECIALISE INLINE pragmas 10:09 PM <dfeuer> mpickering: I'm just going off of the documentation that was added when SPECIALISE INLINE was. 10:09 PM <dfeuer> The only way I know to push really hard for SpecConstr is using that funky pseudo-argument. 10:10 PM <mpickering> there is another deprecated way 10:10 PM <mpickering> but yes you have to use that argument or use a flag I think 10:11 PM <dfeuer> mpickering: well, if the documentation is just wrong, and wasn't intended to be right, then we need to fix the documentation. 10:11 PM <mpickering> indeed, I've just been trying to work out the intention, implementation and documentation line up with each other 10:11 PM <mpickering> as they clearly don't at the moment 10:12 PM <dfeuer> But I do think it's worth considering; the funny special argument is highly unlikely to appear in any other (future) Haskell implementation, so using it is screaming "GHC only forever". }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13016#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler