| 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-bounces@haskell.org] On Behalf Of
| Mikolaj Konarski
| Sent: 20 March 2017 23:41
| To: Matthew Pickering
| Cc: GHC developers
| 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
