#4288: Poor -fspec-constr-count=n warning messages
---------------------------------+------------------------------------------
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.14.2
Component: Compiler | Version: 6.13
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonpj):
Bryan writes: However, several warnings remain, and the Core names are
unidentifiable. More strangely, the SpecConstr limit reported in the
warnings changes from one warning to the next, even within the sequence of
warnings emitted during the compilation of a single file. Here's an
excerpt from compiling only `Data.Text`:
{{{
Function `$wa1{v Xvnq} [lid]'
has one call pattern, but the limit is 0
Function `$w$j{v Xvob} [lid]'
has two call patterns, but the limit is 1
Function `$wa1{v Xvov} [lid]'
has three call patterns, but the limit is 2
}}}
The reason for this odd behaviour is explained in the source code
{{{
Note [Avoiding exponential blowup]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The sc_count field of the ScEnv says how many times we are prepared to
duplicate a single function. But we must take care with recursive
specialiations. Consider
let $j1 = let $j2 = let $j3 = ...
in
...$j3...
in
...$j2...
in
...$j1...
If we specialise $j1 then in each specialisation (as well as the original)
we can specialise $j2, and similarly $j3. Even if we make just *one*
specialisation of each, becuase we also have the original we'll get 2^n
copies of $j3, which is not good.
So when recursively specialising we divide the sc_count by the number of
copies we are making at this level, including the original.
}}}
I don't see a very easy way to fix this problem, so for now I'm just
making sure that all the info is in this one ticket.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4288#comment:2>
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
