[GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function
#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12962 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Feature request: give `-fexpose-all-unfoldings` the same semantics as `INLINABLE` on each function. For simplicity, for the principle of least surprise and for usability of `-fexpose-all-unfoldings`, so that it can actually replace tons of `INLINABLE` that are needed, e.g., for code with lots of abstract class constraints to force it to specialize to the single class that is actually used. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12963 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I should mention that the semantics of `-fexpose-all-unfoldings` is currently different from `INLINABLE` on each function. In particular, it produces much slower programs for my codebase, probably because it doesn't force specialization (though it makes it possible by exposing the unfoldings), as opposed to `INLINABLE`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12963#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This is very vague. You say that the semantics are different but how have you observed this? `INLINABLE` doesn't do anything about "forcing specialisation" so I'm unclear what you mean. If I was to guess I would say that `-fexpose-all-unfoldings` exposes optimised unfoldings rather than unoptimised unfoldings like `INLINABLE`. Now to make progress, do you have a small code sample which behaves differently with `INLINABLE` vs `-fexpose-all-unfoldings`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12963#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12963#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 #12463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: #12962 => #12962 #12463 Comment: Yes, I'm being lazy. I've only benchmarked my big codebase (https://github.com/LambdaHack/LambdaHack). It may not be easy to find a small example in which GHC nevertheless fails to specialize a function for which it has an available unfolding. I got the bit about `INLINABLE` forcing specialization from here: https://ghc.haskell.org/trac/ghc/ticket/12463#comment:8 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12963#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 #12463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => infoneeded -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12963#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 #12463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
Feature request: give `-fexpose-all-unfoldings` the same semantics as INLINABLE on each function.
I don't think we should do this. * `-fexpose-all-unfoldings` has no effect on the optimisation pipeline; it just arranges that, at the end of the pipeline all the unfoldings for all functions are put into the interface file. * `INLINABLE` is quite different. It says to snapshot (essentially the source code of) the RHS of the function, and make it available for inlining and/or specialisation at call sites. So it could have a major effect on the optimisation pipeline. (I'd prefer that it was called `SPECIALISABLE`.) Anyway I don't think it'd be a good idea to make them the same. If you want ''all'' the user-written top-level functions to be `INLINABLE`, we'll need a way to say just that; a reasonable feature request. Perhaps `{-# SPECIALISABLE_ALL #-}`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12963#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 #12463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * status: infoneeded => closed * resolution: => duplicate Comment: Oh, I didn't know the difference between `-fexpose-all-unfoldings` and giving all functions `INLINABLE` is so big and so well defined. Given that, I drop this feature request in favour of #12463. `RECURSIVE_SPECIALISABLE` fits my use case even better and in the worst case the proposal may reduce to something similar to `SPECIALISABLE_ALL`, so I will focus there. Thank you, Simon! Thank you, mpickering! Closing. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12963#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC