for review: stack dumps.

[Tyson Dowd]

On 06-Mar-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > > Here's a comparison.
> > > I have trouble believing the figures myself.
> > > 
> > > Size:
> > > without stack traces:
> > > -rwx------   1 trd      mercury  5046272 Mar  4 19:38 mercury_compile*
> > > with stack traces:
> > > -rwx------   1 trd      mercury  17367040 Mar  5 11:17 mercury_compile*
> > 
> > Um, with a factor of 3 size increase, I'd argue this shouldn't be the
> > default :-).
> 
> At the moment, we store a string giving the name of the label (and other info)
> with every label that is a continuation point. Continuation points occur every
> dozen or so instructions. Due to our label name construction algorithm, the
> label names are very long, so I guess that a doubling of size comes from this
> alone.
> 
> We can do much better. We can store the name of the procedure just once,
> and make the labels in the procedure just give the label number as an int.
> We can even go further, and separate out the module name, and store that
> just once (via llds_common). And of course there is no need to ever store
> the mercury__ prefix on all labels.
> 
> I am in the process of rewriting the continuation label part of the compiler
> to make available variable information at internal trace points. I will take
> the above into consideration.

The other complication is that profiling also needs label names, so
whatever optimizations are made still need to let profiling do its
work.  Ultimately I expect profiling will gather its information from
the stack_layouts.  This is probably not too hard to do, but I'm
refraining from large changes to stack layouts until Zoltan commits his
code.