> > I can look into this, sure, but it wouldn’t exactly solve my original > problem, which is that I would like to turn this on wholesale, not > definition by definition. >
What is "this" that you want to turn on, precisely? why would I ever not want to specialize a definition > I think the only downside is compilation time and code bloat. I think you are concerned about cross-module specialisation. There are two things in play: 1. Whether the defining module exposes the definition 2. Whether the importing module specialises the thus-exposed definition For (1) there are two choices: - (1a) Currently INLINEABLE captures the RHS of the function *exactly as the user wrote it*, and allows that to be specialised. - (1b) On the other hand, -fexpose-all-unfoldings does not attempt to capture the functions the user wrote; instead, it exposes the *post-optimisation *RHSs of all functions, regardless of per-function pragmas. I believe that (1b) is closer to what you want. For (2) one might wonder whether to - (2a) specialise every imported (type-class-overloaded) function whose unfolding we can see - (2b) specialise only imported functions with a SPECIALISABLE pragma - (2c) specialise imported functions only with -fspecialise-aggressively I think GHC currently does (2c). Maybe this taxonomy helps you a bit? Simon On Mon, 9 May 2022 at 02:38, Erdi, Gergo <gergo.e...@sc.com> wrote: > PUBLIC > > > > I can look into this, sure, but it wouldn’t exactly solve my original > problem, which is that I would like to turn this on wholesale, not > definition by definition. It seems that all past discussion about this was > in the context of a per-definition pragma (and sadly, a large part of that > was bikeshedding over the name of the pragma…). But is the reason for that > spelled out explicitly somewhere? In other words, what is the cost of > specialisation, why would I ever not want to specialize a definition > (inlinable or not)? I’d like to understand this first before reviving the > proposal. > > > > *From:* ghc-devs <ghc-devs-boun...@haskell.org> *On Behalf Of *Simon > Peyton Jones > *Sent:* Friday, May 6, 2022 5:26 PM > *To:* Oleg Grenrus <oleg.gren...@iki.fi>; ÉRDI Gergő <ge...@erdi.hu> > *Cc:* GHC developers <ghc-devs@haskell.org> > *Subject:* [External] Re: Specialising NOINLINE functions > > > > There is a (stale) ghc-proposal for that, > https://github.com/ghc-proposals/ghc-proposals/pull/357 > <https://clicktime.symantec.com/3NuNFMzg65dA5k5kXHX5U196xU?u=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F357> > > > > So there is! Thank you. > > > > Gergo: would you like to take over this proposal, revise it if necessary > in the light of the comments, and submit it? > > > > Simon > > > > On Fri, 6 May 2022 at 10:08, Oleg Grenrus <oleg.gren...@iki.fi> wrote: > > There is a (stale) ghc-proposal for that, > https://github.com/ghc-proposals/ghc-proposals/pull/357 > <https://clicktime.symantec.com/3NuNFMzg65dA5k5kXHX5U196xU?u=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F357> > > - Oleg > > On 6.5.2022 12.04, Simon Peyton Jones wrote: > > Dear devs > > > > At the moment the INLINEABLE pragma means "capture my right-hand side, > > regardless of how big it is, so that it can be type-class-specialised, > > including in other modules". But it /also /says "feel free to inline > me". > > > > Some users (eg Gergo) want to say NOINLINE on some functions. But for > > these they'd still like to generate type-class-specialised versions. > > After all, if we aren't going to inline them, specialising is the next > > best thing. > > > > But we have no way to say both "specialise me" and "don't inline me", > > because you can't say both INLINEABLE and NOINLINE. (That would look > > silly.) > > > > I think we should probably just bite the bullet and add a > > SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say > > "capture my right-hand side, regardless of how big it is, so that it > > can be type-class-specialised, including in other modules". It > > behaves exactly like INLINEABLE except that you can specify it along > > with INLINE/NOINLINE. > > > > Any thoughts? Do you think this needs a GHC proposal? > > > > See #21036 < > https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930 > <https://clicktime.symantec.com/3SB6vTf6r7gWFXH7FGMko9a6xU?u=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F21036%23note_407930> > > > > > > > > Simon > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <https://clicktime.symantec.com/37EyM1zQDopVjPevRNvP7f96xU?u=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs> > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <https://clicktime.symantec.com/37EyM1zQDopVjPevRNvP7f96xU?u=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs> > > > This email and any attachments are confidential and may also be > privileged. If you are not the intended recipient, please delete all copies > and notify the sender immediately. You may wish to refer to the > incorporation details of Standard Chartered PLC, Standard Chartered Bank > and their subsidiaries at https: //www.sc.com/en/our-locations > > Where you have a Financial Markets relationship with Standard Chartered > PLC, Standard Chartered Bank and their subsidiaries (the "Group"), > information on the regulatory standards we adhere to and how it may affect > you can be found in our Regulatory Compliance Statement at https: // > www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: // > www.sc.com/rcs/fm > > Insofar as this communication is not sent by the Global Research team and > contains any market commentary, the market commentary has been prepared by > the sales and/or trading desk of Standard Chartered Bank or its affiliate. > It is not and does not constitute research material, independent research, > recommendation or financial advice. Any market commentary is for > information purpose only and shall not be relied on for any other purpose > and is subject to the relevant disclaimers available at https: // > www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > Insofar as this communication is sent by the Global Research team and > contains any research materials prepared by members of the team, the > research material is for information purpose only and shall not be relied > on for any other purpose, and is subject to the relevant disclaimers > available at https: // > research.sc.com/research/api/application/static/terms-and-conditions. > > Insofar as this e-mail contains the term sheet for a proposed transaction, > by responding affirmatively to this e-mail, you agree that you have > understood the terms and conditions in the attached term sheet and > evaluated the merits and risks of the transaction. We may at times also > request you to sign the term sheet to acknowledge the same. > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ > for important information with respect to derivative products. >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
