[m-dev.] for review: factorring out the number of type parameters

[Tyson Dowd]

On 18-May-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> Estimated hours taken: 2
> 
> compiler/stack_layout.m:
> 	Move the number of type parameters from the label layout structures
> 	to the start of the vector of type parameter locations. Since the
> 	vectors are very often common, this saves one word on a large fraction
> 	of all label layout tables.

"vectors are very often common"?  This doesn't sound right.

> 
> 	Fix some documentation rot.
> 
> runtime/mercury_stack_layout.h:
> 	Make the corresponding change in the C description of the layout
> 	structure.
> 
> runtime/mercury_trace_internal.c:
> 	Make the corresponding change in the C code that accesses the layout
> 	structure.
> 
> 	Fix an earlier oversight: don't try to materialize type parameters
> 	that aren't live.
> 
> With --trace all, this change reduces the size of the data segment in the
> executable by a bit over 200 kb, which is about 3.5%.
> 
> Zoltan.
> 
> cvs diff: Diffing .
> cvs diff: Diffing bindist
> cvs diff: Diffing boehm_gc
> cvs diff: Diffing boehm_gc/Mac_files
> cvs diff: Diffing boehm_gc/cord
> cvs diff: Diffing boehm_gc/cord/private
> cvs diff: Diffing boehm_gc/include
> cvs diff: Diffing boehm_gc/include/private
> cvs diff: Diffing bytecode
> cvs diff: Diffing bytecode/test
> cvs diff: Diffing compiler
> Index: compiler/stack_layout.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/stack_layout.m,v
> retrieving revision 1.12
> diff -u -u -r1.12 stack_layout.m
> --- stack_layout.m	1998/05/16 07:30:47	1.12
> +++ stack_layout.m	1998/05/18 07:36:20
> @@ -18,7 +18,7 @@
>  % Modifications by zs.
>  %
>  % NOTE: If you make changes in this file, you may also need to modify
> -% 		runtime/mercury_stack_layout.h
> +% runtime/mercury_stack_layout.h.
>  %
>  %---------------------------------------------------------------------------%
>  %
> @@ -88,8 +88,10 @@
>  % 	live data pairs 	(Word *) - pointer to vector of pairs
>  %				containing MR_Live_Lval and MR_Live_Type
>  % 	live data names	 	(Word *) - pointer to vector of String
> -%	# of type parameters	(Integer)
>  %	type parameters		(Word *) - pointer to vector of MR_Live_Lval
> +%				in which the first word is an Integer
> +%				giving the number of entries in the vector;
> +%				a NULL pointer means no type parameters
>  %
>  % The internal label number field holds either the real label number
>  % (which is always strictly positive), 0 indicating the entry label,
> @@ -107,14 +109,17 @@
>  % of the variable (it is either a pointer to a string, or a NULL pointer,
>  % which means that the variable has no name).
>  %
> -% The number of type parameters is never stored as it is not needed --
> -% the type parameter vector will simply be indexed by the type variable's
> -% variable number stored within pseudo-typeinfos inside the elements
> -% of the live data pairs vectors. Since we allocate type variable numbers
> -% sequentially, the type parameter vector will usually be dense. However,
> -% after all variables whose types include e.g. type variable 2 have gone
> -% out of scope, variables whose types include type variable 3 may still
> -% be around.
> +% If the number of type parameters is not zero, we store the number,
> +% so that the code that needs the type parameters can materialize
> +% all the type parameters from their location descriptions in one go.
> +% This is an optimization, since the type parameter vector could simply
> +% be indexed on demand by the type variable's variable number stored within
> +% pseudo-typeinfos inside the elements of the live data pairs vectors.
> +%
> +% Since we allocate type variable numbers sequentially, the type parameter
> +% vector will usually be dense. However, after all variables whose types
> +% include e.g. type variable 2 have gone out of scope, variables whose
> +% types include type variable 3 may still be around.

An XXX stating the implications this has for extra optimizations in 
llds_common might be nice here (but not essential).

>  %
>  % We need detailed information about the variables that are live at an
>  % internal label in two kinds of circumstances. Stack layout information
> @@ -136,9 +141,9 @@
>  % to the live data names vector will be NULL unless the first condition
>  % holds for the label (i.e. the label is used in execution tracing).
>  %
> -% XXX: Presently, type parameter vectors are not created, and
> -% inst information is ignored. We also do not yet enable procid stack
> -% layouts for profiling, since profiling does not yet use stack layouts.
> +% XXX: Presently, inst information is ignored. We also do not yet enable
> +% procid stack layouts for profiling, since profiling does not yet use
> +% stack layouts.
>  %
>  %---------------------------------------------------------------------------%
>  
> @@ -423,17 +428,20 @@
>  			NamesRval),
>  
>  		{ set__to_sorted_list(TVarLocnSet, TVarLocns) },
> -		stack_layout__construct_type_param_locn_vector(TVarLocns, 1,
> -			TypeParamLocs),
> -		stack_layout__get_next_cell_number(CNum1),
> -		{ TypeParamRval = create(0, TypeParamLocs, no, CNum1,
> -			"stack_layout_type_param_locn_vector") },
> -		{ list__length(TypeParamLocs, TypeParamsLength) },
> -		{ TypeParamLengthRval = const(int_const(TypeParamsLength)) },
> -
> +		( { TVarLocns = [] } ->
> +			{ TypeParamRval = const(int_const(0)) }
> +		;
> +			stack_layout__construct_type_param_locn_vector(
> +				TVarLocns, 1, TypeParamLocs),
> +			{ list__length(TypeParamLocs, TypeParamsLength) },
> +			{ LengthRval = const(int_const(TypeParamsLength)) },
> +			{ Vector = [yes(LengthRval) | TypeParamLocs] },
> +			stack_layout__get_next_cell_number(CNum1),
> +			{ TypeParamRval = create(0, Vector, no, CNum1,
> +				"stack_layout_type_param_locn_vector") }
> +		),
>  		{ RvalList = [yes(VarLengthRval), yes(LiveValRval),
> -			yes(NamesRval), yes(TypeParamLengthRval),
> -			yes(TypeParamRval)] }
> +			yes(NamesRval), yes(TypeParamRval)] }
>  	;
>  		{ RvalList = [yes(VarLengthRval)] }
>  	).
> cvs diff: Diffing compiler/notes
> cvs diff: Diffing doc
> cvs diff: Diffing extras
> cvs diff: Diffing extras/cgi
> cvs diff: Diffing extras/complex_numbers
> cvs diff: Diffing extras/complex_numbers/samples
> cvs diff: Diffing extras/complex_numbers/tests
> cvs diff: Diffing extras/graphics
> cvs diff: Diffing extras/graphics/Togl-1.2
> cvs diff: Diffing extras/graphics/mercury_opengl
> cvs diff: Diffing extras/graphics/mercury_tcltk
> cvs diff: Diffing extras/graphics/samples
> cvs diff: Diffing extras/graphics/samples/calc
> cvs diff: Diffing extras/graphics/samples/maze
> cvs diff: Diffing extras/odbc
> cvs diff: Diffing extras/references
> cvs diff: Diffing extras/trailed_update
> cvs diff: Diffing extras/trailed_update/samples
> cvs diff: Diffing library
> cvs diff: Diffing lp_solve
> cvs diff: Diffing lp_solve/lp_examples
> cvs diff: Diffing profiler
> cvs diff: Diffing runtime
> Index: runtime/mercury_stack_layout.h
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/runtime/mercury_stack_layout.h,v
> retrieving revision 1.5
> diff -u -u -r1.5 mercury_stack_layout.h
> --- mercury_stack_layout.h	1998/05/16 07:28:19	1.5
> +++ mercury_stack_layout.h	1998/05/18 06:53:53
> @@ -257,8 +257,22 @@
>  typedef	struct MR_Stack_Layout_Vars_Struct {
>  	MR_Stack_Layout_Var	*MR_slvs_pairs;
>  	String			*MR_slvs_names;
> -	Integer			MR_slvs_tvar_count;
>  	MR_Live_Lval		*MR_slvs_tvars;
> +				/*
> +				** If MR_slvs_tvars == NULL, there are no
> +				** type parameters. If it is != NULL, then
> +				** (Integer) MR_slvs_tvars[0] is the index
> +				** of the highest numbered type parameter,
> +				** and MR_slvs_tvars[i] for values of i
> +				** between 1 and (Integer) MR_slvs_tvars[0]
> +				** (both inclusive) describe the location
> +				** of the typeinfo structure for the type
> +				** variable of the corresponding number.
> +				** If one of these type variables is not
> +				** referred to by the variables described in
> +				** MR_slvs_pairs, the corresponding entry
> +				** will be zero.
> +				*/

Is it necessary for the entry to be zero?  If we allow it to contain
any value, we can (potentially) share more vectors. 

Otherwise, this change is fine.

-- 
       Tyson Dowd           # So I asked Sarah: what's the serial number on
                            # your computer? She replied:
     trd at cs.mu.oz.au        #          A-C-2-4-0-V-/-5-0-H-Z
http://www.cs.mu.oz.au/~trd #