#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: |
---------------------------------+------------------------------------------
Comment(by nomeata):
Replying to [comment:5 simonmar]:
> 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 latter, in my opinion.
> 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.
I’m not sure what this means in terms of the implementation of `call` and
`push` – or is this fulfilled by any “call-push-algebra“ (and therefore
the current and my proposed one)?
> 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.
Yes, this does not hold by my definition:
{{{
call (push y <CAF,main,x,y,x>) <CAF,main,x,y,x>
== call <CAF,main,x,y> <CAF,main,x,y,x>
== <CAF,main,x,y,x>
/= <CAF,main,x,y>
== (push y <CAF,main,x,y,x>)
}}}
So by the requirements you state, my definition fares just as well as
yours.
I thought about being explicit about recursions, i.e. shortning
<CAF,main,x,y,x,y,x,y> as <CAF,main,(x,y)3> (and maybe representing it by
a special “repeat the n CC’s below” value in the CC stack). This would not
lose any information, call could be implemented to fulfill your equation
and the (individual) stacks would still be bounded in size. But due to the
memorization in the current code it seems that all such stacks would stay
around and probably consume too much memory in the presence of recursion;
if that were acceptable then you wouldn’t have introduced any truncating
in the first place, would you?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7240#comment:6>
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
