Inifinite inlining loop
Ganesh Sittampalam reports:
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
My code does have a recursive datatype, but the recursion isn't contravariant, which is the case described in "Secrets of the GHC inliner", 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
Here is the 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