exhausted simplifier ticks and hs-boot files

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

exhausted simplifier ticks and hs-boot files

Ganesh Sittampalam
Hi,

The code below (also attached - unzip and run go.sh) triggers the GHC
panic "Simplifier ticks exhausted", and I'm unsure whether I should view
it as an instance of the known infelicity in the inliner
(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#bugs-ghc)

My code does have a recursive datatype, but the recursion isn't
contravariant, which is the case described in "Secrets of the GHC
inliner"
(https://www.microsoft.com/en-us/research/wp-content/uploads/2002/07/inline.pdf,
section 4).

It's cut down from some real code where I have a mutually recursive
datatype that I want to define across two modules for code structuring
reasons, meaning I need a .hs-boot file. I haven't been able to
reproduce it without the .hs-boot file - if I put everything in one
module it stops happening.

I've tried with a range of GHC versions from 8.2.x to an early version
of 8.8. It happens with -O1 and not -O0, but I haven't managed to find a
specific optimisation that triggers it.

Is this just an instance of the known problem in a different guise, or
is it something different and worth a bug report?

Cheers,

Ganesh

T2.hs-boot
-----------
module T2 where

data T2

mapP_T2 :: (Int -> Int) -> T2 -> T2

T1.hs
-----
module T1 where

import {-# SOURCE #-} T2

data T1 = T1 T2

mapP_T1 :: (Int -> Int) -> T1 -> T1
mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs)

T2.hs
-----

module T2 where

import T1

data T2 = T2 T1

mapP_T2 :: (Int -> Int) -> T2 -> T2
mapP_T2 f (T2 t) = T2 (mapP_T1 f t)

go :: T1 -> T1
go = mapP_T1 id

GHC output
----------
$ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats)
[...]
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 8.2.2 for x86_64-unknown-mingw32):
        Simplifier ticks exhausted
  When trying UnfoldingDone mapP_T2
  To increase the limit, use -fsimpl-tick-factor=N (default 100)
  If you need to do this, let GHC HQ know, and what factor you needed
  Total ticks:     61203

  24481 PreInlineUnconditionally
    6121 ds_i17h
    6120 f_a16p
    6120 ds_d17d
    6120 ds1_i17i
  12241 UnfoldingDone
    6121 mapP_T1
    6120 mapP_T2
  24481 BetaReduction
    6121 ds_i17h
    6120 f_a16p
    6120 ds_d17d
    6120 ds1_i17i

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Simpl.zip (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: exhausted simplifier ticks and hs-boot files

Haskell - Glasgow-haskell-users mailing list
Ganesh

It's an old bug that has somehow reappeared.
I opened https://gitlab.haskell.org/ghc/ghc/issues/17140

But it seems OK in HEAD, and hence probably in GHC 8.8.  Can you try?

Maybe put further comments on the issue tracker, rather than here.

thanks

Simon

| -----Original Message-----
| From: Glasgow-haskell-users <[hidden email]> On
| Behalf Of Ganesh Sittampalam
| Sent: 05 August 2019 14:02
| To: [hidden email]
| Subject: exhausted simplifier ticks and hs-boot files
|
| Hi,
|
| The code below (also attached - unzip and run go.sh) triggers the GHC
| panic "Simplifier ticks exhausted", and I'm unsure whether I should view
| it as an instance of the known infelicity in the inliner
| (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html
| #bugs-ghc)
|
| My code does have a recursive datatype, but the recursion isn't
| contravariant, which is the case described in "Secrets of the GHC inliner"
| (https://www.microsoft.com/en-us/research/wp-
| content/uploads/2002/07/inline.pdf,
| section 4).
|
| It's cut down from some real code where I have a mutually recursive
| datatype that I want to define across two modules for code structuring
| reasons, meaning I need a .hs-boot file. I haven't been able to reproduce
| it without the .hs-boot file - if I put everything in one module it stops
| happening.
|
| I've tried with a range of GHC versions from 8.2.x to an early version of
| 8.8. It happens with -O1 and not -O0, but I haven't managed to find a
| specific optimisation that triggers it.
|
| Is this just an instance of the known problem in a different guise, or is
| it something different and worth a bug report?
|
| Cheers,
|
| Ganesh
|
| T2.hs-boot
| -----------
| module T2 where
|
| data T2
|
| mapP_T2 :: (Int -> Int) -> T2 -> T2
|
| T1.hs
| -----
| module T1 where
|
| import {-# SOURCE #-} T2
|
| data T1 = T1 T2
|
| mapP_T1 :: (Int -> Int) -> T1 -> T1
| mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs)
|
| T2.hs
| -----
|
| module T2 where
|
| import T1
|
| data T2 = T2 T1
|
| mapP_T2 :: (Int -> Int) -> T2 -> T2
| mapP_T2 f (T2 t) = T2 (mapP_T1 f t)
|
| go :: T1 -> T1
| go = mapP_T1 id
|
| GHC output
| ----------
| $ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats) [...]
| ghc.exe: panic! (the 'impossible' happened)
|   (GHC version 8.2.2 for x86_64-unknown-mingw32):
|         Simplifier ticks exhausted
|   When trying UnfoldingDone mapP_T2
|   To increase the limit, use -fsimpl-tick-factor=N (default 100)
|   If you need to do this, let GHC HQ know, and what factor you needed
|   Total ticks:     61203
|
|   24481 PreInlineUnconditionally
|     6121 ds_i17h
|     6120 f_a16p
|     6120 ds_d17d
|     6120 ds1_i17i
|   12241 UnfoldingDone
|     6121 mapP_T1
|     6120 mapP_T2
|   24481 BetaReduction
|     6121 ds_i17h
|     6120 f_a16p
|     6120 ds_d17d
|     6120 ds1_i17i
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users