#14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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 simonpj): There is something odd here. In comment:2 I proposed: * NOSPECIALISABLE: please do not specialise this function (even if it would otherwise be easy to do so) * NOINLINE: please do not inline or specialise this function (even if it would otherwise be easy to do so). That is, hide its implementation from the caller. But it seems odd to allow a function to be inlined, but not to allow it to be specialised, doesn't it? After all, inlining is really just a drastic form of specialisation: once per call site! You can think of specialisation as a way to economise on all these inlinings by sharing them among similar call sites. So I wonder whether we should reverse the semantics thus: * NOINLINE: please do not inline this function (even if it would otherwise be easy to do so). But GHC is free to specialise it. * NOSPECIALISABLE: please do not inline or specialise this function (even if it would otherwise be easy to do so). You could also argue for inlining and specialisation to be orthogonal, but that'd lead to strange cases where you (accidentally perhaps) say to inline but never specialise or some other odd combination. I'm inclined to stick with four mutually-exclusive settings for now. Anyone else care to comment? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14239#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler