#5539: GHC panic - Simplifier ticks exhausted
---------------------------------+------------------------------------------
Reporter: hvr | Owner: simonpj
Type: bug | Status: new
Priority: high | Milestone: 7.4.1
Component: Compiler | Version: 7.3
Resolution: | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Compile-time crash | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
---------------------------------+------------------------------------------
Comment(by rl):
Thanks for the explanation, Simon. I (once again) forgot that GHC will
only inline functions that are explicitly marked INLINE into unfoldings.
IMO, if there is such a significant difference between INLINE functions
and very small functions like not which we basically expect to always be
inlined, then all those functions should be marked as INLINE in the
libraries. If would be even better if there was no difference, though!
I also don't understand why GHC should just stop simplifying at some
point. Yes, it might take a while but it *will* finish. I'm don't really
understand the motivation behind this simplifier ticks business. Could we
perhaps have a way to turn it off just like we can turn off !SpecConstr
thresholds?
In the end, it seems that I'll have to switch to using the preprocessor
rather than relying on GHC to eliminate `if False` which really is a pity.
In C, I can write `if(0)` and a reasonable compiler will eliminate the
code without any problems.
Note that those are only internal checks so they would never be turned on
in end-user code. However, there is also proper bounds checking which
might lead to similar problems in user-defined loops. Here, not inlining
indexing functions isn't an option as it will to huge slowdowns. I'm not
sure what to do there except for recommending to users to avoid large
loops with explicit indexing. This really seems extremely unfortunate.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5539#comment:30>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
