[m-dev.] for review: fix stack traces (runtime)

[Zoltan Somogyi]

>  	(const Word *) &mercury_data__stack_layout__##e,		\
> +	(Integer) -1,		/* Unknown label number */		\
>  	(Integer) -1,		/* Unknown number of live values */	\
> -	(const Word *) NULL	/* No list of live valeus */		\
> +	(const Word *) NULL,	/* No vector of live values */		\
> +	(const Word *) NULL,	/* No vector of variable names */	\
> +	(const Word *) NULL	/* No vector of type parameters */	\

The semantics of the label record says that if the number of live values
is zero, the other fields are not valid (and thus need not be present).
This should also be the case if the number of live values slot has a
negative number. This should save a few words in the library and runtime.

> +		if (determinism != -1) {

Why don't you say

		if (determinism < 0)
			break;

This makes the test more robust, avoids executing it twice, and gives
you one tab more room.

A comment saying what a negative determinism signifies would also be
nice, since I for one don't know what it means.

> +				fprintf(stderr, "\t%s\n", label->e_name);

mercury_label.h has

typedef struct s_label {
        const char      *e_name;   /* name of the procedure          */
        Code            *e_addr;   /* address of the code            */
        Word            *e_layout; /* layout info for the procedure  */
} Label;

The comment on e_layout seems wrong, since to be useful for agc, the
pointer must be to the layout info for the label, not the procedure.

The e_name field is now redundant. The name of the procedure can be assembled
(in a user friendly form even) from the pieces in the procedure layout info,
which is accessible from the label layout info. Removing it would also
reduce data space requirements significantly. The duplication of info that
is also the procedure layout (in a format which is more amenable
to factoring out the common module part, the module name) would be gone.
This duplication was probably responsible for a large part of the
extraordinary increase of the (-g, Alpha) executable size from 8.x Mb to
62.x Mb with --generate-trace.

The layout records for labels in hand-written code may need to be
provided with a pointer to a sufficiently meaningful procedure layout
record if this were done. OTOH, many if not most of these should
probably be skipped by the stack trace anyway.

I don't believe we ever need the e_name field for a label which has
no layout record. In fact, I don't believe we ever need a label table entry
for any label which has no layout record, except maybe for profiling.
Does anybody know of such a need?

If my supposition is true, or can be made true with minimal effort, we can
avoid emitting the non _sl versions of the label init macros.

Zoltan.