[m-dev.] for review: deep profiling changes [part 2/3]

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Mar 10 18:17:55 AEDT 2000


On 26-Feb-2000, Thomas Conway <conway at cs.mu.OZ.AU> wrote:
> Index: compiler/mercury_compile.m
...
> +mercury_compile__maybe_compute_sccs(HLDS0, Verbose, Stats, HLDS) -->
> +	globals__io_lookup_bool_option(errorcheck_only, ErrorCheckOnly),
> +	globals__io_lookup_bool_option(profile_deep, DeepProfiling),
> +	(
> +		{ ErrorCheckOnly = no },
> +		{ DeepProfiling = yes }
> +	->
> +		maybe_write_string(Verbose, "% Computing SCC information...\n"),
> +		maybe_flush_output(Verbose),
> +		{ profiling__compute_scc_info(HLDS0, HLDS) },

Hmm, maybe_compute_sccs is called only from middle_pass,
and middle_pass is never called if errorcheck_only is `yes'.
So I don't think there is any need to check errorcheck_only here.

(The same comment applies to the existing code in inlining.m
which you probably cut-and-paste this code from.  I've just
fixed that.)

> Index: compiler/rl_code.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/rl_code.m,v
> retrieving revision 1.9
> diff -u -r1.9 rl_code.m
> --- compiler/rl_code.m	1999/09/07 05:48:54	1.9
> +++ compiler/rl_code.m	2000/02/25 23:39:25
> @@ -63,6 +63,7 @@
>  
>  :- type bytecode	--->
>  		rl_EXP_bool_immed(int32)
> +/*
>  	;	rl_EXP_int_immed(int32)
>  	;	rl_EXP_bool_push(int32)
>  	;	rl_EXP_int_push(int32)
> @@ -419,6 +420,7 @@
>  	;	rl_HEAD_var_stream(int32)
>  	;	rl_HEAD_define_rule(int32,int32,int32)
>  	;	rl_HEAD_last_bytecode
> +*/
>  	.
>  
>  
> @@ -445,6 +447,7 @@
>  	int16_to_bytecode(0, I0Codes),
>  	int32_to_bytecode(X0int32, X0int32Codes),
>  	list__condense([I0Codes,X0int32Codes], Splits).
> +/*
>  bytecode_to_intlist(rl_EXP_int_immed(X0int32),	 Splits) :-
>  	int16_to_bytecode(1, I1Codes),
>  	int32_to_bytecode(X0int32, X0int32Codes),
> @@ -1714,6 +1717,7 @@
>  bytecode_to_intlist(rl_HEAD_last_bytecode,	 Splits) :-
>  	int16_to_bytecode(356, I356Codes),
>  	list__condense([I356Codes], Splits).
> +*/
>  
>  int32_to_bytecode(X, List) :-
>  	int32_to_byte_list(X, List).

Uh, I think the Aditi group will not be very happy if you
commit those changes... was that intentional?

> Index: compiler/stack_layout.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/stack_layout.m,v
> retrieving revision 1.43
> diff -u -r1.43 stack_layout.m
> --- compiler/stack_layout.m	2000/01/14 01:10:43	1.43
> +++ compiler/stack_layout.m	2000/02/25 23:39:36
> @@ -46,6 +46,7 @@
>  %	predicate name		(String)
>  %	predicate arity		(int_least16_t)
>  %	procedure number	(int_least16_t)
> +%	owner scc id		(Word) actually MR_SCCId *
>  %
>  % Automatically generated unification, index and comparison predicates
>  % use the second form:
> @@ -56,6 +57,7 @@
>  %	predicate name		(String)
>  %	predicate arity		(int_least16_t)
>  %	procedure number	(int_least16_t)
> +%	owner scc id		(Word) actually MR_SCCId *

Using an integer type to hold a pointer in something that
will be statically initialized is not portable.
If you do need to use some generic type, you should use a
pointer type such as `void *' or `Word *'.

> @@ -270,6 +272,7 @@
>  	module_info_name(ModuleInfo0, ModuleName),
>  	module_info_get_cell_count(ModuleInfo0, CellCount),
>  	module_info_globals(ModuleInfo0, Globals),
> +	% module_info_get_scc_info(ModuleInfo0, scc_info(ProcSCCs, _)),

You should either delete that commented-out line of code,
or add a comment explaining why the code is commented out.

> -:- pred stack_layout__construct_procid_rvals(proc_label::in,
> +:- pred stack_layout__construct_procid_rvals(proc_label::in, maybe(rval)::in,
>  	list(maybe(rval))::out, initial_arg_types::out) is det.
>  
> -stack_layout__construct_procid_rvals(ProcLabel, Rvals, ArgTypes) :-
> +stack_layout__construct_procid_rvals(ProcLabel, SCCId0, Rvals, ArgTypes) :-
> +	(
> +		SCCId0 = yes(_),
> +		SCCIdElem = [SCCId0],
> +		SCCIdElemType = [1 - no]

I think the `no' there will need to change,
if you change the type from `Word' (see my earlier comment).

> @@ -784,9 +792,10 @@
>  				yes(const(string_const(DefModuleString))),
>  				yes(const(string_const(PredName))),
>  				yes(const(int_const(Arity))),
> -				yes(const(int_const(Mode)))
> +				yes(const(int_const(Mode)))|
> +				SCCIdElem
>  			],
> -		ArgTypes = [4 - no, 2 - yes(int_least16)]
> +		ArgTypes = [4 - no, 2 - yes(int_least16)|SCCIdElemType]

s/|/ | /

>  	;
>  		ProcLabel = special_proc(DefModule, PredName, TypeModule,
>  			TypeName, Arity, ProcId),
> @@ -799,9 +808,10 @@
>  				yes(const(string_const(DefModuleString))),
>  				yes(const(string_const(PredName))),
>  				yes(const(int_const(Arity))),
> -				yes(const(int_const(Mode)))
> +				yes(const(int_const(Mode)))|
> +				SCCIdElem

s/|/ |/

>  			],
> -		ArgTypes = [4 - no, 2 - yes(int_least16)]
> +		ArgTypes = [4 - no, 2 - yes(int_least16)|SCCIdElemType]

s/|/ | /

> +stack_layout__construct_closure_layout(UsingStackLayouts, ProcLabel, SCCId,
> +		ClosureLayoutInfo, Rvals, ArgTypes, CNum0, CNum) :-
...
> +		ProcIdRval = create(0, ProcIdRvals,
> +			initial(ProcIdTypes, none), must_be_static,
> +			CNum0, "proc_layout_vector", no),
> +		CNum1 = CNum0 + 1

You should double-check that you are using the same
convention with regard to ++CNum vs CNum++
as the rest of the code.

Hmm, I just checked it myself, and it looks to me like
you are using the opposite convention.
It would be nice to use the `counter' type that Zoltan
just posted for review here.  But that should be a
separate change.  For now, just make sure you use
`CNum' rather than `CNum0' in the arguments of create/7.

> +	Rvals = [yes(ProcIdRval)|LayoutRvals],

s/|/ | /

> Index: compiler/unify_gen.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/unify_gen.m,v
> retrieving revision 1.104
> diff -u -r1.104 unify_gen.m
> --- compiler/unify_gen.m	2000/01/14 01:10:46	1.104
> +++ compiler/unify_gen.m	2000/02/25 23:39:38
> @@ -41,6 +41,7 @@
>  :- import_module hlds_module, hlds_pred, prog_data, prog_out, code_util.
>  :- import_module mode_util, type_util, code_aux, hlds_out, tree, arg_info.
>  :- import_module globals, options, continuation_info, stack_layout.
> +:- import_module profiling.
>  
>  :- import_module term, bool, string, int, list, map, require, std_util.
>  
> @@ -530,8 +531,13 @@
>  		{ code_util__extract_proc_label_from_code_addr(CodeAddr,
>  			ProcLabel) },
>  		code_info__get_cell_count(CNum0),
> -		{ stack_layout__construct_closure_layout(ProcLabel,
> -			ClosureInfo, ClosureLayoutMaybeRvals,
> +		profiling__scc_id(proc(PredId, ProcId), SCCId),
> +		code_info__get_globals(Globals),
> +		{ globals__lookup_bool_option(Globals, procid_stack_layout,
> +			StackLayouts) },
> +		{ stack_layout__construct_closure_layout(StackLayouts,
> +			ProcLabel, SCCId, ClosureInfo,
> +			ClosureLayoutMaybeRvals,
>  			ClosureLayoutArgTypes, CNum0, CNum) },

Hmm, shouldn't (at least part of) that be inside a test
to see whether the deep_profiling option is set?
What will profiling__scc_id do if we haven't computed the SCCs?

> @@ -190,6 +193,7 @@
>  vn_type__vnrval_type(vn_stackvar_addr(_), data_ptr).
>  vn_type__vnrval_type(vn_framevar_addr(_), data_ptr).
>  vn_type__vnrval_type(vn_heap_addr(_, _, _), data_ptr).
> +vn_type__vnrval_type(vn_c_func(_, _, _, _), word).

Shouldn't that use the return type lval_type field of the
vn_c_func functor, rather than `word'?

> Index: library/array.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/library/array.m,v
> retrieving revision 1.67
> diff -u -r1.67 array.m
> --- library/array.m	2000/01/19 09:45:16	1.67
> +++ library/array.m	2000/02/25 23:39:49
> @@ -276,6 +276,26 @@
>  Declare_entry(mercury__array__array_equal_2_0);
>  Declare_entry(mercury__array__array_compare_3_0);
>  
> +#ifdef MR_PROFILE_DEEP
> +  MR_MAKE_SCC_ID(unify_array_scc_id, { }, { }, { });
> +  MR_MAKE_PROC_LAYOUT(mercury____Unify___array__array_1_0,
> +  	MR_DETISM_SEMI, MR_ENTRY_NO_SLOT_COUNT, MR_LONG_LVAL_TYPE_UNKNOWN,
> +	MR_PREDICATE, ""array"", ""builtin_compare"", 2, 0,
> +	unify_array_scc_id);
> +
> +  MR_MAKE_SCC_ID(index_array_scc_id, { }, { }, { });
> +  MR_MAKE_PROC_LAYOUT(mercury____Index___array__array_1_0,
> +  	MR_DETISM_DET, MR_ENTRY_NO_SLOT_COUNT, MR_LONG_LVAL_TYPE_UNKNOWN,
> +	MR_PREDICATE, ""array"", ""builtin_index"", 2, 0,
> +	index_array_scc_id);
> +
> +  MR_MAKE_SCC_ID(compare_array_scc_id, { }, { }, { });
> +  MR_MAKE_PROC_LAYOUT(mercury____Compare___array__array_1_0,
> +  	MR_DETISM_DET, MR_ENTRY_NO_SLOT_COUNT, MR_LONG_LVAL_TYPE_UNKNOWN,
> +	MR_PREDICATE, ""array"", ""builtin_index"", 3, 0,
> +	compare_array_scc_id);
> +#endif

Pretty much the same code appears for the unification/index/compare
predicates for array__array, pred, c_pointer, private_builtin__type_info,
private_builtin__typeclass_info, std_util__univ, and std_util__type_info.
I think it would be worth defining a single macro that would expand to 
this code, rather than duplicating the code seven times.

> Index: runtime/mercury_ho_call.c
...
> +#ifdef MR_PROF_DEEP
> +MR_MAKE_HO_CALL_SITE(genu_to_specu, mercury__unify_2_0, "runtime", 334);
> +MR_MAKE_SCC_ID(unify_scc_id, { }, { &genu_to_specu }, { });
> +MR_MAKE_PROC_LAYOUT(mercury__unify_2_0, MR_DETISM_SEMI, 0, 0,
> +			MR_PREDICATE, "builtin", "unify", 2, 0,
> +			unify_scc_id);
> +
> +MR_MAKE_HO_CALL_SITE(geni_to_speci, mercury__index_2_0, "builtin", 574);

What are the magic numbers 334, 574, etc. here?

> @@ -268,13 +318,59 @@
>  				restore_registers();
>  			}
>  
> +#ifndef MR_PROFILE_DEEP
>  			tailcall(type_ctor_info->unify_pred,
>  				LABEL(mercury__unify_2_0));
> +#else
> +{
> +			/*
> +			** When doing deep profiling, we need to
> +			** make a stack frame and treat the call
> +			** the way user HO calls get treated,
> +			** except that instead of using an MR_Closure
> +			** we use the 
> +			*/

That comment is incomplete.

(This occurs in several places.)

> Index: runtime/mercury_prof.c
> @@ -111,6 +114,9 @@
>  ** Local function declarations
>  */
>  
> +void
> +checked_atexit(void (*func)(void));

If that function is local, it should be declared static.
If it is not, then it should be declared in the header
file rather than in the .c file.

> Index: runtime/mercury_stack_layout.h
...
>  #define MR_MAKE_PROC_LAYOUT(entry, detism, slots, succip_locn,		\
> -		pf, module, name, arity, mode) 				\
> -	MR_Stack_Layout_Entry mercury_data__layout__##entry = {		\
> +		pf, module, name, arity, mode, sccd)			\
> +	const struct mercury_data__layout__##entry##_struct { 		\
> +		/* stack traversal group */				\
> +		Code			*MR_sle_code_addr;		\
> +		MR_Long_Lval		MR_sle_succip_locn;		\
> +		MR_int_least16_t	MR_sle_stack_slots;		\
> +		MR_Determinism		MR_sle_detism;			\
> +		/* proc id group */					\
> +		MR_Stack_Layout_Proc_Id MR_sle_proc_id;			\
> +	} mercury_data__layout__##entry = {				\
>  		MR_MAKE_PROC_LAYOUT_ADDR(entry),			\
>  		succip_locn,						\
>  		slots,							\

Could you explain that change for me?
I don't understand why you can't use MR_Stack_Layout_Entry.

> Index: runtime/mercury_type_info.h
...
> @@ -848,6 +848,11 @@
>  	String				type_ctor_module_name;
>  	String				type_ctor_name;
>  	Integer				type_ctor_version;
> +#ifdef MR_PROFILE_DEEP
> +	const Word			*unify_info;
> +	const Word			*index_info;
> +	const Word			*compare_info;
> +#endif

It would be a good idea to have some comments here explaining the
meaning and format of the data that these pointers point to.

> @@ -882,7 +892,16 @@
>  		NULL,							\
>  		MR_string_const(MR_STRINGIFY(m), sizeof(MR_STRINGIFY(m))-1),\
>  		MR_string_const(MR_STRINGIFY(n), sizeof(MR_STRINGIFY(n))-1),\
> -		MR_RTTI_VERSION						\
> +		MR_RTTI_VERSION,					\
> +	MR_IF_PROFILE_DEEP(						\
> +		(const Word *) MR_REF_SLEc(u)				\
> +	)								\
> +	MR_IF_PROFILE_DEEP(						\
> +		(const Word *) MR_REF_SLEc(i)				\
> +	)								\
> +	MR_IF_PROFILE_DEEP(						\
> +		(const Word *) MR_REF_SLEc(c)				\
> +	)								\

I think it would be clearer to use a single invocation of
MR_IF_PROFILE_DEEP() here.  Also, that code looks buggy:
isn't it missing some commas between the different items?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list