#7240: Stack trace truncated too much with indirect recursion
---------------------------------+------------------------------------------
Reporter: nomeata | Owner: nomeata
Type: bug | Status: new
Priority: normal | Milestone:
Component: Profiling | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Changes (by simonmar):
* difficulty: => Unknown
Comment:
I like your original idea (only truncating on a real loop), but I don't
understand the explanation of why it didn't work. Is it a bug in
`enterCCSFun`, or just a consequence of the way it works?
The way I like to think about this problem is in terms of equalities. I
want two equalities to hold:
{{{
push L (\x.e) == \x. push L e
let f = \x.e in E[f] == E[\x.e]
}}}
I'm using `==` to mean that the stacks are the same, in some sense.
Perhaps a more precise way is to say that the stack when evaluating `e` is
the same in both cases.
The first one tells us that it is ok to move a `push` inside a lambda,
which in turn tells us that `push` scopes over the body of a lambda, which
is the behaviour we want.
The second one corresponds to inlining, which is a transformation that GHC
performs all the time. We need it to be the case that inlining a function
does not change the stack.
The second equality gives rise to this:
{{{
call (push f S) S == push f S
}}}
which is not satisfied by the current definition of `call` and `push`,
because `push f S` might truncate the stack (the same applies to your
definition too, I believe). One definition that does work is to ignore
the second and subsequent occurrences of labels in the stack, but that
gives bad results for other reasons.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7240#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
