SPECIALISE INLINE pragma

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

SPECIALISE INLINE pragma

Matthew Pickering
The user guide says that "you can make GHC diverge by using SPECIALISE
INLINE on an ordinarily-recursive function."

Does anyone know the ticket or technique which causes this to happen?

https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#specialize-inline


On the same topic, I also wrote a blog post simply explaining the
essential things to know
about the inliner and specialiser as I don't think they are generally
appreciated. Comments welcome!

http://mpickering.github.io/posts/2017-03-20-inlining-and-specialisation.html

Matt
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: SPECIALISE INLINE pragma

Mikolaj Konarski-2
> On the same topic, I also wrote a blog post simply explaining the
> essential things to know
> about the inliner and specialiser as I don't think they are generally
> appreciated. Comments welcome!
>
> http://mpickering.github.io/posts/2017-03-20-inlining-and-specialisation.html

LGTM. I'd propose to link to this from GHC manual.

I didn't know the bit about INLINE being ignored
on a loop-breaker with no warning and no way of changing
the loop-breaker. That probably explains puzzling
and counter-intuitive results of some alternative layouts
of INLINEs in the computation-intensive parts of my code,
at least since the time I provide unfoldings for all functions
and so discounts don't help GHC in picking the intended loop-breaker.
And I don't think this ignoring of the programmer's intent
wrt INLINE is documented in the usual places.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: SPECIALISE INLINE pragma

GHC - devs mailing list
In reply to this post by Matthew Pickering
|  On the same topic, I also wrote a blog post simply explaining the
|  essential things to know about the inliner and specialiser as I don't
|  think they are generally appreciated. Comments welcome!
|  
|  http://mpickering.github.io/posts/2017-03-20-inlining-and-
|  specialisation.html

Fantastic work Matthew.

Might you put in the "Collaborative documentation" section of the Haskell wiki?  https://wiki.haskell.org/GHC

That way others could help edit/maintain/extend it.  I have quite a few suggestions, but most are easier just to execute than to send you suggested deltas.


|  The user guide says that "you can make GHC diverge by using SPECIALISE
|  INLINE on an ordinarily-recursive function."

Suppose you have

f x = ...(f [x])...

Now I think SPECIALISE INLINE might go on for ever, making more and more specialised copies.  At least I think that's it.  Making a concrete example and putting that in the manual would be great.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:[hidden email]] On Behalf Of
|  Matthew Pickering
|  Sent: 20 March 2017 15:52
|  To: GHC developers <[hidden email]>
|  Subject: SPECIALISE INLINE pragma
|  
|  The user guide says that "you can make GHC diverge by using SPECIALISE
|  INLINE on an ordinarily-recursive function."
|  
|  Does anyone know the ticket or technique which causes this to happen?
|  
|  https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgo
|  w_exts.html#specialize-inline
|  
|  
|  
|  Matt
|  _______________________________________________
|  ghc-devs mailing list
|  [hidden email]
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: SPECIALISE INLINE pragma

GHC - devs mailing list
In reply to this post by Mikolaj Konarski-2
|  I didn't know the bit about INLINE being ignored on a loop-breaker
|  with no warning and no way of changing the loop-breaker.

GHC tries hard NOT to choose an INLINE function as a loop breaker.  But if you write

f x = if ... then 0 else (f x')
{-# INLINE f #-}

then the only possible loop breaker is 'f', so GHC has to choose it.

What else would you suggest?  What puzzling behaviour do you have in mind?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:[hidden email]] On Behalf Of
|  Mikolaj Konarski
|  Sent: 20 March 2017 23:41
|  To: Matthew Pickering <[hidden email]>
|  Cc: GHC developers <[hidden email]>
|  Subject: Re: SPECIALISE INLINE pragma
|  
|  > On the same topic, I also wrote a blog post simply explaining the
|  > essential things to know about the inliner and specialiser as I
|  don't
|  > think they are generally appreciated. Comments welcome!
|  >
|  > http://mpickering.github.io/posts/2017-03-20-inlining-and-
|  specialisati
|  > on.html
|  
|  LGTM. I'd propose to link to this from GHC manual.
|  
|  I didn't know the bit about INLINE being ignored on a loop-breaker
|  with no warning and no way of changing the loop-breaker. That probably
|  explains puzzling and counter-intuitive results of some alternative
|  layouts of INLINEs in the computation-intensive parts of my code, at
|  least since the time I provide unfoldings for all functions and so
|  discounts don't help GHC in picking the intended loop-breaker.
|  And I don't think this ignoring of the programmer's intent wrt INLINE
|  is documented in the usual places.
|  _______________________________________________
|  ghc-devs mailing list
|  [hidden email]
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: SPECIALISE INLINE pragma

Matthew Pickering
In reply to this post by GHC - devs mailing list
Thanks Simon.

I made a page for it here - https://wiki.haskell.org/Inlining_and_Specialisation

Matt

On Wed, Mar 22, 2017 at 10:50 AM, Simon Peyton Jones
<[hidden email]> wrote:

> |  On the same topic, I also wrote a blog post simply explaining the
> |  essential things to know about the inliner and specialiser as I don't
> |  think they are generally appreciated. Comments welcome!
> |
> |  http://mpickering.github.io/posts/2017-03-20-inlining-and-
> |  specialisation.html
>
> Fantastic work Matthew.
>
> Might you put in the "Collaborative documentation" section of the Haskell wiki?  https://wiki.haskell.org/GHC
>
> That way others could help edit/maintain/extend it.  I have quite a few suggestions, but most are easier just to execute than to send you suggested deltas.
>
>
> |  The user guide says that "you can make GHC diverge by using SPECIALISE
> |  INLINE on an ordinarily-recursive function."
>
> Suppose you have
>
> f x = ...(f [x])...
>
> Now I think SPECIALISE INLINE might go on for ever, making more and more specialised copies.  At least I think that's it.  Making a concrete example and putting that in the manual would be great.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:[hidden email]] On Behalf Of
> |  Matthew Pickering
> |  Sent: 20 March 2017 15:52
> |  To: GHC developers <[hidden email]>
> |  Subject: SPECIALISE INLINE pragma
> |
> |  The user guide says that "you can make GHC diverge by using SPECIALISE
> |  INLINE on an ordinarily-recursive function."
> |
> |  Does anyone know the ticket or technique which causes this to happen?
> |
> |  https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgo
> |  w_exts.html#specialize-inline
> |
> |
> |
> |  Matt
> |  _______________________________________________
> |  ghc-devs mailing list
> |  [hidden email]
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: SPECIALISE INLINE pragma

Mikolaj Konarski-2
In reply to this post by GHC - devs mailing list
> GHC tries hard NOT to choose an INLINE function as a loop breaker.  But if you write
>
> f x = if ... then 0 else (f x')
> {-# INLINE f #-}
>
> then the only possible loop breaker is 'f', so GHC has to choose it.

Indeed.

> What else would you suggest?

A warning would be very welcome. Given that the debugging
compiler emits one, perhaps it's not too difficult to add.

Apart of that, if the heuristics is based not on INLINE pragmas,
but on available unfoldings, as Matthew suggests in his wiki article,
I'd propose to fix that, see the case below.

> What puzzling behaviour do you have in mind?

I can't reconstruct it now, but I was profiling as set of mutually
recursive functions, with -fexpose-all-unfoldings (so GHC could not
decide based on available unfoldings) and INLINE on only some
of them (I don't remember if the others had NOINLINE or nothing).
I had an impression some of the INLINEs where ignored and that
the loop breaker was not at the place I was forcing, but the impression
was based only on comparison of runtimes of different variants,
not on inspecting core. A warning would really help next time
to let me catch a concrete example to post.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: SPECIALISE INLINE pragma

GHC - devs mailing list
|  A warning would be very welcome. Given that the debugging compiler
|  emits one, perhaps it's not too difficult to add.

That's a good idea; but it's a bit tricky: see Trac #9418.

It _must_ be possible to do better here.

Simon

|  -----Original Message-----
|  From: Mikolaj Konarski [mailto:[hidden email]]
|  Sent: 23 March 2017 21:15
|  To: Simon Peyton Jones <[hidden email]>
|  Cc: Matthew Pickering <[hidden email]>; GHC developers
|  <[hidden email]>
|  Subject: Re: SPECIALISE INLINE pragma
|  
|  > GHC tries hard NOT to choose an INLINE function as a loop breaker.
|  > But if you write
|  >
|  > f x = if ... then 0 else (f x')
|  > {-# INLINE f #-}
|  >
|  > then the only possible loop breaker is 'f', so GHC has to choose it.
|  
|  Indeed.
|  
|  > What else would you suggest?
|  
|  A warning would be very welcome. Given that the debugging compiler
|  emits one, perhaps it's not too difficult to add.
|  
|  Apart of that, if the heuristics is based not on INLINE pragmas, but
|  on available unfoldings, as Matthew suggests in his wiki article, I'd
|  propose to fix that, see the case below.
|  
|  > What puzzling behaviour do you have in mind?
|  
|  I can't reconstruct it now, but I was profiling as set of mutually
|  recursive functions, with -fexpose-all-unfoldings (so GHC could not
|  decide based on available unfoldings) and INLINE on only some of them
|  (I don't remember if the others had NOINLINE or nothing).
|  I had an impression some of the INLINEs where ignored and that the
|  loop breaker was not at the place I was forcing, but the impression
|  was based only on comparison of runtimes of different variants, not on
|  inspecting core. A warning would really help next time to let me catch
|  a concrete example to post.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs