[External] Re: Specialising NOINLINE functions

Mon May 9 08:12:57 UTC 2022

>
> 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.Erdi at 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-bounces at haskell.org> *On Behalf Of *Simon
> Peyton Jones
> *Sent:* Friday, May 6, 2022 5:26 PM
> *To:* Oleg Grenrus <oleg.grenrus at iki.fi>; ÉRDI Gergő <gergo at erdi.hu>
> *Cc:* GHC developers <ghc-devs at 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.grenrus at 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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220509/2a94a06c/attachment.html>