Re: Specialization plugin

[Matthew Pickering]

I am helping Ryan investigate this.

See https://ghc.haskell.org/trac/ghc/ticket/12791 for one example
which we have identified so far.

Matt

On Fri, Oct 28, 2016 at 10:14 PM, Simon Peyton Jones via ghc-devs
 wrote:
> I’d really like to know why INLINABLE pragmas don’t work. Perhaps an
> example?
>
>
>
> Only the type checker currently can conjure up dictionaries.  It would
> presumably not be impossible to do so later, but it’d be quite a new thing,
> involving invoking the constraint solver.  The pattern-match overlap checker
> does this; but without needing to generate any evidence bindings.
>
>
>
> But let’s see what’s wrong with INLINABLE first.  After all if there’s a bug
> there, fixing it will benefit everyone.
>
>
>
> SImon
>
>
>
> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ryan
> Trinkle
> Sent: 28 October 2016 00:06
> To: ghc-devs@haskell.org
> Subject: Specialization plugin
>
>
>
> Hi everyone,
>
>
>
> I'm trying my hand at writing a GHC plugin to generate specializations for
> all uses of a particular typeclass, and I've run into some trouble.  I'd
> appreciate it if someone could point me in the right direction!  I'm new to
> GHC development, so I may just be overlooking some simple stuff.
>
>
>
> The original problem:
>
> Reflex's interface is presented as a typeclass, which allows the underlying
> FRP engine to be selected by instance resolution.  Although some programs
> make use of this (particularly the semantics test suite), most only ever use
> one implementation.  However, since their code is typically written
> polymorphically, the implementation cannot be inlined and its rewrite rules
> cannot fire.  This means that the typeclass
>
>
>
> My attempted solutions:
>
>  * Initially, I wrote a plugin that adds INLINABLE pragmas to everything.
> This helped; small programs now generally see the inlining/rule-firings I
> was hoping for.  However, in large programs, this does not occur.  I'm
> looking into this, but also trying another approach:
>
>  * Now, I am attempting to write a plugin that adds a SPECIALIZE pragma to
> every binding whose type mentions Reflex.
>
>
>
> The trouble:
>
> Since SPECIALIZE pragmas seem to be removed during typechecking
> (DsBinds.dsSpec), I can't directly add them.  I would like to, perhaps,
> invoke Specialise.specBind; however, I'm not sure how to obtain the
> necessary instance - as mentioned here, "only the type checker can conjure
> [dictionaries] up".  Perhaps it's possible to explicitly create that
> dictionary somewhere and extract it for use during the plugin pass?
>
>
>
>
>
> Thanks,
>
> Ryan
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialization plugin

[Ryan Trinkle]

My understanding was that they ought to be the same.  However, that didn't
seem to be the case.  In my small example, where the plugin did work,
-fexpose-all-unfoldings did not.

On Sun, Oct 30, 2016 at 8:23 AM, Christiaan Baaij <
christiaan.ba...@gmail.com> wrote:

> One small question: what's the difference between adding INLINABLE
> everywhere, and just compiling with -fexpose-all-unfoldings,
> https://downloads.haskell.org/~ghc/latest/docs/html/users_
> guide/using-optimisation.html#ghc-flag--fexpose-all-unfoldings? Is there
> any reason you couldn't use that flag as opposed to writing a plugin that
> adds INLINEABLE pragmas to all bindings?
>
> On 28 October 2016 at 00:05, Ryan Trinkle  wrote:
>
>> Hi everyone,
>>
>> I'm trying my hand at writing a GHC plugin to generate specializations
>> for all uses of a particular typeclass, and I've run into some trouble.
>> I'd appreciate it if someone could point me in the right direction!  I'm
>> new to GHC development, so I may just be overlooking some simple stuff.
>>
>> The original problem:
>> Reflex's interface is presented as a typeclass, which allows the
>> underlying FRP engine to be selected by instance resolution.  Although some
>> programs make use of this (particularly the semantics test suite), most
>> only ever use one implementation.  However, since their code is typically
>> written polymorphically, the implementation cannot be inlined and its
>> rewrite rules cannot fire.  This means that the typeclass
>>
>> My attempted solutions:
>>  * Initially, I wrote a plugin that adds INLINABLE pragmas to
>> everything.  This helped; small programs now generally see the
>> inlining/rule-firings I was hoping for.  However, in large programs, this
>> does not occur.  I'm looking into this, but also trying another approach:
>>  * Now, I am attempting to write a plugin that adds a SPECIALIZE pragma
>> to every binding whose type mentions Reflex.
>>
>> The trouble:
>> Since SPECIALIZE pragmas seem to be removed during typechecking
>> (DsBinds.dsSpec), I can't directly add them.  I would like to, perhaps,
>> invoke Specialise.specBind; however, I'm not sure how to obtain the
>> necessary instance - as mentioned here
>> ,
>> "only the type checker can conjure [dictionaries] up".  Perhaps it's
>> possible to explicitly create that dictionary somewhere and extract it for
>> use during the plugin pass?
>>
>>
>> Thanks,
>> Ryan
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialization plugin

[Christiaan Baaij]

One small question: what's the difference between adding INLINABLE
everywhere, and just compiling with -fexpose-all-unfoldings,
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using-optimisation.html#ghc-flag--fexpose-all-unfoldings?
Is there any reason you couldn't use that flag as opposed to writing a
plugin that adds INLINEABLE pragmas to all bindings?

On 28 October 2016 at 00:05, Ryan Trinkle  wrote:

> Hi everyone,
>
> I'm trying my hand at writing a GHC plugin to generate specializations for
> all uses of a particular typeclass, and I've run into some trouble.  I'd
> appreciate it if someone could point me in the right direction!  I'm new to
> GHC development, so I may just be overlooking some simple stuff.
>
> The original problem:
> Reflex's interface is presented as a typeclass, which allows the
> underlying FRP engine to be selected by instance resolution.  Although some
> programs make use of this (particularly the semantics test suite), most
> only ever use one implementation.  However, since their code is typically
> written polymorphically, the implementation cannot be inlined and its
> rewrite rules cannot fire.  This means that the typeclass
>
> My attempted solutions:
>  * Initially, I wrote a plugin that adds INLINABLE pragmas to everything.
> This helped; small programs now generally see the inlining/rule-firings I
> was hoping for.  However, in large programs, this does not occur.  I'm
> looking into this, but also trying another approach:
>  * Now, I am attempting to write a plugin that adds a SPECIALIZE pragma to
> every binding whose type mentions Reflex.
>
> The trouble:
> Since SPECIALIZE pragmas seem to be removed during typechecking
> (DsBinds.dsSpec), I can't directly add them.  I would like to, perhaps,
> invoke Specialise.specBind; however, I'm not sure how to obtain the
> necessary instance - as mentioned here
> ,
> "only the type checker can conjure [dictionaries] up".  Perhaps it's
> possible to explicitly create that dictionary somewhere and extract it for
> use during the plugin pass?
>
>
> Thanks,
> Ryan
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialization plugin

[Ryan Trinkle]

I definitely plan to investigate the INLINABLE thing.  In small programs,
it all appears to be working as expected.  However, in a larger (~50
modules) client project, I think (but have not 100% confirmed) that it is
not specializing everything.  The Core certainly has a good number of
Reflex dictionaries floating around (I would ideally hope that they would
all be eliminated).  Perhaps there is an issue relating to INLINABLE
crossing many module or package boundaries.

I'll follow up when I have more info about exactly how that's breaking,
along with an example I can share (the current one is confidential to my
client).

On Fri, Oct 28, 2016 at 5:14 PM, Simon Peyton Jones 
wrote:

> I’d really like to know why INLINABLE pragmas don’t work. Perhaps an
> example?
>
>
>
> Only the type checker currently can conjure up dictionaries.  It would
> presumably not be impossible to do so later, but it’d be quite a new thing,
> involving invoking the constraint solver.  The pattern-match overlap
> checker does this; but without needing to generate any evidence bindings.
>
>
>
> But let’s see what’s wrong with INLINABLE first.  After all if there’s a
> bug there, fixing it will benefit everyone.
>
>
>
> SImon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Ryan
> Trinkle
> *Sent:* 28 October 2016 00:06
> *To:* ghc-devs@haskell.org
> *Subject:* Specialization plugin
>
>
>
> Hi everyone,
>
>
>
> I'm trying my hand at writing a GHC plugin to generate specializations for
> all uses of a particular typeclass, and I've run into some trouble.  I'd
> appreciate it if someone could point me in the right direction!  I'm new to
> GHC development, so I may just be overlooking some simple stuff.
>
>
>
> The original problem:
>
> Reflex's interface is presented as a typeclass, which allows the
> underlying FRP engine to be selected by instance resolution.  Although some
> programs make use of this (particularly the semantics test suite), most
> only ever use one implementation.  However, since their code is typically
> written polymorphically, the implementation cannot be inlined and its
> rewrite rules cannot fire.  This means that the typeclass
>
>
>
> My attempted solutions:
>
>  * Initially, I wrote a plugin that adds INLINABLE pragmas to everything.
> This helped; small programs now generally see the inlining/rule-firings I
> was hoping for.  However, in large programs, this does not occur.  I'm
> looking into this, but also trying another approach:
>
>  * Now, I am attempting to write a plugin that adds a SPECIALIZE pragma to
> every binding whose type mentions Reflex.
>
>
>
> The trouble:
>
> Since SPECIALIZE pragmas seem to be removed during typechecking
> (DsBinds.dsSpec), I can't directly add them.  I would like to, perhaps,
> invoke Specialise.specBind; however, I'm not sure how to obtain the
> necessary instance - as mentioned here
> ,
> "only the type checker can conjure [dictionaries] up".  Perhaps it's
> possible to explicitly create that dictionary somewhere and extract it for
> use during the plugin pass?
>
>
>
>
>
> Thanks,
>
> Ryan
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Specialization plugin

[Simon Peyton Jones via ghc-devs]

I’d really like to know why INLINABLE pragmas don’t work. Perhaps an example?

Only the type checker currently can conjure up dictionaries.  It would 
presumably not be impossible to do so later, but it’d be quite a new thing, 
involving invoking the constraint solver.  The pattern-match overlap checker 
does this; but without needing to generate any evidence bindings.

But let’s see what’s wrong with INLINABLE first.  After all if there’s a bug 
there, fixing it will benefit everyone.

SImon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ryan Trinkle
Sent: 28 October 2016 00:06
To: ghc-devs@haskell.org
Subject: Specialization plugin

Hi everyone,

I'm trying my hand at writing a GHC plugin to generate specializations for all 
uses of a particular typeclass, and I've run into some trouble.  I'd appreciate 
it if someone could point me in the right direction!  I'm new to GHC 
development, so I may just be overlooking some simple stuff.

The original problem:
Reflex's interface is presented as a typeclass, which allows the underlying FRP 
engine to be selected by instance resolution.  Although some programs make use 
of this (particularly the semantics test suite), most only ever use one 
implementation.  However, since their code is typically written 
polymorphically, the implementation cannot be inlined and its rewrite rules 
cannot fire.  This means that the typeclass

My attempted solutions:
 * Initially, I wrote a plugin that adds INLINABLE pragmas to everything.  This 
helped; small programs now generally see the inlining/rule-firings I was hoping 
for.  However, in large programs, this does not occur.  I'm looking into this, 
but also trying another approach:
 * Now, I am attempting to write a plugin that adds a SPECIALIZE pragma to 
every binding whose type mentions Reflex.

The trouble:
Since SPECIALIZE pragmas seem to be removed during typechecking 
(DsBinds.dsSpec), I can't directly add them.  I would like to, perhaps, invoke 
Specialise.specBind; however, I'm not sure how to obtain the necessary instance 
- as mentioned 
here,
 "only the type checker can conjure [dictionaries] up".  Perhaps it's possible 
to explicitly create that dictionary somewhere and extract it for use during 
the plugin pass?


Thanks,
Ryan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs