RE: SPECIALISE INLINE pragma

2017-03-27 Thread Simon Peyton Jones via ghc-devs 
|  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:miko...@well-typed.com]
|  Sent: 23 March 2017 21:15
|  To: Simon Peyton Jones <simo...@microsoft.com>
|  Cc: Matthew Pickering <matthewtpicker...@gmail.com>; GHC developers
|  <ghc-devs@haskell.org>
|  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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SPECIALISE INLINE pragma

2017-03-23 Thread Mikolaj Konarski 
> 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SPECIALISE INLINE pragma

2017-03-22 Thread Matthew Pickering 
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
 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:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Matthew Pickering
> |  Sent: 20 March 2017 15:52
> |  To: GHC developers 
> |  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
> |  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: SPECIALISE INLINE pragma

2017-03-22 Thread Simon Peyton Jones via ghc-devs 
|  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:ghc-devs-boun...@haskell.org] On Behalf Of
|  Mikolaj Konarski
|  Sent: 20 March 2017 23:41
|  To: Matthew Pickering <matthewtpicker...@gmail.com>
|  Cc: GHC developers <ghc-devs@haskell.org>
|  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
|  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: SPECIALISE INLINE pragma

2017-03-22 Thread Simon Peyton Jones via ghc-devs 
|  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:ghc-devs-boun...@haskell.org] On Behalf Of
|  Matthew Pickering
|  Sent: 20 March 2017 15:52
|  To: GHC developers 
|  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
|  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: SPECIALISE INLINE pragma

2017-03-20 Thread Mikolaj Konarski 
> 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs