[GHC] #13090: Expose all unfoldings of overloaded functions by default
#13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: Differential Rev(s): Phab:D2929 | Wiki Page: -------------------------------------+------------------------------------- Users expect their overloaded functions to be specialised at call sites, however, this is only the case if they are either lucky and GHC chooses to include the unfolding or they mark their definition with an INLINABLE pragma. This leads to library authors marking all their functions with INLINABLE (or more accurately INLINE) so they ensure that downstream consumers pay no cost for their abstraction. A more sensible default is to do this job for the library author and give more predictable guarantees about specialisation. Empirically, I compiled a selection of 1150 packages with (a similar) patch applied. The total size of the interface files before the patch was 519mb and after 634mb. On modern machines, I think this increase is justified for the result. This is a ticket to track the progress of D2929. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13090 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | Differential Rev(s): Phab:D2929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not sure I agree with either * Users expect their overloaded functions to be specialised at call sites or * A more sensible default is to [copy the code of every overloaded function into every module which uses it once for every time at which it is used] I would be more worried about the effects on program size and compile time than on interface file size. Maybe instead an opt-in flag `-fexpose-all- overloaded-unfoldings`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13090#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | Differential Rev(s): Phab:D2929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): As a user, yes, I would welcome an easy way to have "overloaded functions specialised at call sites". Attaching a pragma to each of them is not "easy", but a compiler option (per module, or per cabal project) is. If compile times/code sizes go up, so be it. It's a price to pay for faster executables. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13090#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | Differential Rev(s): Phab:D2929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:2 j.waldmann]:
As a user, yes, I would welcome an easy way to have "overloaded functions specialised at call sites".
But there must be limits surely. For example in GHC there are plenty of functions that are hundreds of lines long. They happen to (mostly?) not be overloaded, but if they were then it would surely not be sensible to copy them into every client module once for every type at which they are used.
Attaching a pragma to each of them is not "easy", but a compiler option (per module, or per cabal project) is.
Sure, but a compiler option is not "by default".
If compile times/code sizes go up, so be it. It's a price to pay for faster executables.
If you opt into it, okay. Slow compile times are pretty much the most common complaint about GHC as far as I've seen. mpickering suggested on IRC that we might by default only do this for small functions; I'd be much happier about that (and it does seem like it would have real runtime performance gains). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13090#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | Differential Rev(s): Phab:D2929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Yes, I meant "opt-in" (for paying the price). Sorry, I did not understand that this ticket is about doing this per default. I should have read the discussion in the Phab ticket first. I guess you could count my remark as a vote for "-O3" suggested in https://phabricator.haskell.org/D2929#85930 Feel free to disregard (if you want this ticket here to be free of discussion). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13090#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC