defunctionalization

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

defunctionalization

Nicolas Frisby
I'd like to put a NOINLINE and an INLINABLE pragma on a binding.

(I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS
to make it into the interface file, but I do not want it to be inlined,
since that'd undo the defunctionalization.)

In other words, I'd like a CoreUnfolding value with the uf_guidance =
UnfNever.

It seems TidyPgm.addExternal ignores such a core unfolding.

Would GHC consider a patch to make this work?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130716/a3f30965/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

defunctionalization

Nicolas Frisby
Ah, I misread that TidyPgm function.It looks like if I build the
CoreUnfolding, GHC will respect it. It's just rejecting the pragma
combination in HsSyn.

On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <nicolas.frisby at gmail.com> wrote:
>
> I'd like to put a NOINLINE and an INLINABLE pragma on a binding.
>
> (I'm sketching a defunctionalization pass. I'd like the 'apply` routine
RHS to make it into the interface file, but I do not want it to be inlined,
since that'd undo the defunctionalization.)
>
> In other words, I'd like a CoreUnfolding value with the uf_guidance =
UnfNever.
>
> It seems TidyPgm.addExternal ignores such a core unfolding.
>
> Would GHC consider a patch to make this work?
>
> Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130716/c2f488ec/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

defunctionalization

Simon Peyton Jones
It seems a little weird, but the internal data types can express it, so if you can make the front end do the right thing I'd be happy to take it.  (Don't forget the manual.)

SImon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Nicolas Frisby
Sent: 16 July 2013 21:29
To: ghc-devs at haskell.org
Subject: Re: defunctionalization


Ah, I misread that TidyPgm function.It looks like if I build the CoreUnfolding, GHC will respect it. It's just rejecting the pragma combination in HsSyn.

On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <nicolas.frisby at gmail.com<mailto:nicolas.frisby at gmail.com>> wrote:

>
> I'd like to put a NOINLINE and an INLINABLE pragma on a binding.
>
> (I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS to make it into the interface file, but I do not want it to be inlined, since that'd undo the defunctionalization.)
>
> In other words, I'd like a CoreUnfolding value with the uf_guidance = UnfNever.
>
> It seems TidyPgm.addExternal ignores such a core unfolding.
>
> Would GHC consider a patch to make this work?
>
> Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130718/662119b3/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

defunctionalization

Andrew Farmer
What happens when you put NOINLINE on the function and compile with
-fexpose-all-unfoldings? Does that get the behavior you want?


On Thu, Jul 18, 2013 at 2:20 AM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  It seems a little weird, but the internal data types can express it, so
> if you can make the front end do the right thing I?d be happy to take it.
> (Don?t forget the manual.)****
>
> ** **
>
> SImon****
>
> ** **
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
> Frisby
> *Sent:* 16 July 2013 21:29
> *To:* ghc-devs at haskell.org
> *Subject:* Re: defunctionalization****
>
> ** **
>
> Ah, I misread that TidyPgm function.It looks like if I build the
> CoreUnfolding, GHC will respect it. It's just rejecting the pragma
> combination in HsSyn.****
>
> On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <nicolas.frisby at gmail.com>
> wrote:
> >
> > I'd like to put a NOINLINE and an INLINABLE pragma on a binding.
> >
> > (I'm sketching a defunctionalization pass. I'd like the 'apply` routine
> RHS to make it into the interface file, but I do not want it to be inlined,
> since that'd undo the defunctionalization.)
> >
> > In other words, I'd like a CoreUnfolding value with the uf_guidance =
> UnfNever.
> >
> > It seems TidyPgm.addExternal ignores such a core unfolding.
> >
> > Would GHC consider a patch to make this work?
> >
> > Thanks.****
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130718/9556211a/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

defunctionalization

Nicolas Frisby
I think that would work, but I was looking for something more precise.


On Thu, Jul 18, 2013 at 12:24 PM, Andrew Farmer <afarmer at ittc.ku.edu> wrote:

> What happens when you put NOINLINE on the function and compile with
> -fexpose-all-unfoldings? Does that get the behavior you want?
>
>
> On Thu, Jul 18, 2013 at 2:20 AM, Simon Peyton-Jones <simonpj at microsoft.com
> > wrote:
>
>>  It seems a little weird, but the internal data types can express it, so
>> if you can make the front end do the right thing I?d be happy to take it.
>> (Don?t forget the manual.)****
>>
>> ** **
>>
>> SImon****
>>
>> ** **
>>
>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
>> Frisby
>> *Sent:* 16 July 2013 21:29
>> *To:* ghc-devs at haskell.org
>> *Subject:* Re: defunctionalization****
>>
>> ** **
>>
>> Ah, I misread that TidyPgm function.It looks like if I build the
>> CoreUnfolding, GHC will respect it. It's just rejecting the pragma
>> combination in HsSyn.****
>>
>> On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <nicolas.frisby at gmail.com>
>> wrote:
>> >
>> > I'd like to put a NOINLINE and an INLINABLE pragma on a binding.
>> >
>> > (I'm sketching a defunctionalization pass. I'd like the 'apply` routine
>> RHS to make it into the interface file, but I do not want it to be inlined,
>> since that'd undo the defunctionalization.)
>> >
>> > In other words, I'd like a CoreUnfolding value with the uf_guidance =
>> UnfNever.
>> >
>> > It seems TidyPgm.addExternal ignores such a core unfolding.
>> >
>> > Would GHC consider a patch to make this work?
>> >
>> > Thanks.****
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130718/56803cb5/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

defunctionalization

Nicolas Frisby
In reply to this post by Simon Peyton Jones
This table outlines my plan for the compatibility of the pragmas.

Each cell is formatted as "x/y", where "x" answers "Is the original RHS in
the interface file?" and "y" answers "Will GHC try to inline it?".

               NOINLINE   INLINABLE   INLINE
<none>         no/no      yes/yes     yes/enthusiastically

NOINLINE       error      yes/no      error
INLINABLE      -          error       error
INLINE         -          -           error

The proposed new "yes/no" option gives the GHC user more control. It
prevents GHC from inlining a function while still supporting the ability to
use the annotated function's RHS in another module, via SPECIALISE or the
special "inline" function. Moreover, the presence of the RHS in the .hi
file could be used by tools other than GHC like plugins or a super-compiler.


On Thu, Jul 18, 2013 at 4:20 AM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  It seems a little weird, but the internal data types can express it, so
> if you can make the front end do the right thing I?d be happy to take it.
> (Don?t forget the manual.)****
>
> ** **
>
> SImon****
>
> ** **
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
> Frisby
> *Sent:* 16 July 2013 21:29
> *To:* ghc-devs at haskell.org
> *Subject:* Re: defunctionalization****
>
> ** **
>
> Ah, I misread that TidyPgm function.It looks like if I build the
> CoreUnfolding, GHC will respect it. It's just rejecting the pragma
> combination in HsSyn.****
>
> On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <nicolas.frisby at gmail.com>
> wrote:
> >
> > I'd like to put a NOINLINE and an INLINABLE pragma on a binding.
> >
> > (I'm sketching a defunctionalization pass. I'd like the 'apply` routine
> RHS to make it into the interface file, but I do not want it to be inlined,
> since that'd undo the defunctionalization.)
> >
> > In other words, I'd like a CoreUnfolding value with the uf_guidance =
> UnfNever.
> >
> > It seems TidyPgm.addExternal ignores such a core unfolding.
> >
> > Would GHC consider a patch to make this work?
> >
> > Thanks.****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130718/314ae272/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

defunctionalization

Carter Schonwald
So the idea here to make it possible to have a function that can be
specialized at certain types, and  explicitly inlined at specific use
sites, but ghc otherwise will not inline it? Cool!

one thought: might it be simpler to instead have something like
EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas
which "seem" contradictory?



On Thu, Jul 18, 2013 at 3:30 PM, Nicolas Frisby <nicolas.frisby at gmail.com>wrote:

> This table outlines my plan for the compatibility of the pragmas.
>
> Each cell is formatted as "x/y", where "x" answers "Is the original RHS in
> the interface file?" and "y" answers "Will GHC try to inline it?".
>
>                NOINLINE   INLINABLE   INLINE
> <none>         no/no      yes/yes     yes/enthusiastically
>
> NOINLINE       error      yes/no      error
> INLINABLE      -          error       error
> INLINE         -          -           error
>
> The proposed new "yes/no" option gives the GHC user more control. It
> prevents GHC from inlining a function while still supporting the ability to
> use the annotated function's RHS in another module, via SPECIALISE or the
> special "inline" function. Moreover, the presence of the RHS in the .hi
> file could be used by tools other than GHC like plugins or a super-compiler.
>
>
> On Thu, Jul 18, 2013 at 4:20 AM, Simon Peyton-Jones <simonpj at microsoft.com
> > wrote:
>
>>  It seems a little weird, but the internal data types can express it, so
>> if you can make the front end do the right thing I?d be happy to take it.
>> (Don?t forget the manual.)****
>>
>> ** **
>>
>> SImon****
>>
>> ** **
>>
>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
>> Frisby
>> *Sent:* 16 July 2013 21:29
>> *To:* ghc-devs at haskell.org
>> *Subject:* Re: defunctionalization****
>>
>> ** **
>>
>> Ah, I misread that TidyPgm function.It looks like if I build the
>> CoreUnfolding, GHC will respect it. It's just rejecting the pragma
>> combination in HsSyn.****
>>
>> On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <nicolas.frisby at gmail.com>
>> wrote:
>> >
>> > I'd like to put a NOINLINE and an INLINABLE pragma on a binding.
>> >
>> > (I'm sketching a defunctionalization pass. I'd like the 'apply` routine
>> RHS to make it into the interface file, but I do not want it to be inlined,
>> since that'd undo the defunctionalization.)
>> >
>> > In other words, I'd like a CoreUnfolding value with the uf_guidance =
>> UnfNever.
>> >
>> > It seems TidyPgm.addExternal ignores such a core unfolding.
>> >
>> > Would GHC consider a patch to make this work?
>> >
>> > Thanks.****
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130718/6d17206f/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

defunctionalization

Carter Schonwald
naively, it might really blow up compilation times perhaps? (i'm
speculating on the compilation time possibility)
 Large haskell projects do take a while to build as is, so any changes that
can blow up compilation times really merit being thoughtful.


On Thu, Jul 18, 2013 at 6:20 PM, Andrew Farmer <xichekolas at gmail.com> wrote:

> Maybe this is a good time to ask, since I've always been curious... is
> there a reason -fexpose-all-unfoldings is not the default?
>
> That is, is there a strong reason to not include the original RHS of
> *every* exported function in the interface file, regardless of its
> INLINE/NOINLINE status? This would greatly benefit HERMIT users, for
> example... or other plugins that do some form of partial evaluation.
>
> I realize interface files would be bigger, but disk is cheap. They would
> also change more often, maybe triggering more recompilation? Thoughts?
>
> Drew
> On Jul 18, 2013 3:10 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
> wrote:
>
>> So the idea here to make it possible to have a function that can be
>> specialized at certain types, and  explicitly inlined at specific use
>> sites, but ghc otherwise will not inline it? Cool!
>>
>> one thought: might it be simpler to instead have something like
>> EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas
>> which "seem" contradictory?
>>
>>
>>
>> On Thu, Jul 18, 2013 at 3:30 PM, Nicolas Frisby <nicolas.frisby at gmail.com
>> > wrote:
>>
>>> This table outlines my plan for the compatibility of the pragmas.
>>>
>>> Each cell is formatted as "x/y", where "x" answers "Is the original RHS
>>> in the interface file?" and "y" answers "Will GHC try to inline it?".
>>>
>>>                NOINLINE   INLINABLE   INLINE
>>> <none>         no/no      yes/yes     yes/enthusiastically
>>>
>>> NOINLINE       error      yes/no      error
>>> INLINABLE      -          error       error
>>> INLINE         -          -           error
>>>
>>> The proposed new "yes/no" option gives the GHC user more control. It
>>> prevents GHC from inlining a function while still supporting the ability to
>>> use the annotated function's RHS in another module, via SPECIALISE or the
>>> special "inline" function. Moreover, the presence of the RHS in the .hi
>>> file could be used by tools other than GHC like plugins or a super-compiler.
>>>
>>>
>>> On Thu, Jul 18, 2013 at 4:20 AM, Simon Peyton-Jones <
>>> simonpj at microsoft.com> wrote:
>>>
>>>>  It seems a little weird, but the internal data types can express it,
>>>> so if you can make the front end do the right thing I?d be happy to take
>>>> it.  (Don?t forget the manual.)****
>>>>
>>>> ** **
>>>>
>>>> SImon****
>>>>
>>>> ** **
>>>>
>>>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
>>>> Frisby
>>>> *Sent:* 16 July 2013 21:29
>>>> *To:* ghc-devs at haskell.org
>>>> *Subject:* Re: defunctionalization****
>>>>
>>>> ** **
>>>>
>>>> Ah, I misread that TidyPgm function.It looks like if I build the
>>>> CoreUnfolding, GHC will respect it. It's just rejecting the pragma
>>>> combination in HsSyn.****
>>>>
>>>> On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <nicolas.frisby at gmail.com>
>>>> wrote:
>>>> >
>>>> > I'd like to put a NOINLINE and an INLINABLE pragma on a binding.
>>>> >
>>>> > (I'm sketching a defunctionalization pass. I'd like the 'apply`
>>>> routine RHS to make it into the interface file, but I do not want it to be
>>>> inlined, since that'd undo the defunctionalization.)
>>>> >
>>>> > In other words, I'd like a CoreUnfolding value with the uf_guidance =
>>>> UnfNever.
>>>> >
>>>> > It seems TidyPgm.addExternal ignores such a core unfolding.
>>>> >
>>>> > Would GHC consider a patch to make this work?
>>>> >
>>>> > Thanks.****
>>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130719/439879c6/attachment.htm>