> Estimated hours taken: 20
>
> Reorganize options for accurate GC, stack tracing and execution tracing.
> Add live value information (at entry and exit) for execution tracing.
The log message should have a summary of the new options.
> + % Generate the list of lval - live_value_type pairs and the
> + % typeinfo variable - lval pairs for any type variables in
> + % the types of the input variables.
> +
> +:- pred code_gen__generate_lvaltypes(list(var), list(lval),
> + assoc_list(lval, live_value_type), assoc_list(var, lval),
> + code_info, code_info).
> +:- mode code_gen__generate_lvaltypes(in, in, out, out, in, out) is det.
Don't you want to use this predicate for the output args as well?
> +code_gen__generate_lvaltypes(Vars, Lvals, LvalTypes, TypeInfos) -->
> + code_info__get_instmap(InstMap),
> + list__map_foldl(code_info__variable_type, Vars, Types),
> + { list__map(instmap__lookup_var(InstMap), Vars, Insts) },
> + { assoc_list__from_corresponding_lists(Types, Insts,
> + TypeInsts) },
> + { list__map(lambda([TypeInst::in, LiveType::out] is det, (
> + TypeInst = Type - Inst,
> + LiveType = var(Type, Inst))),
> + TypeInsts, LiveTypes) },
It may be worthwhile adding a new predicate to assoc_list.m that
invokes a user-supplied predicate for each pair of list elements,
instead of wrapping them up inside a pair, before putting the result
into the zipped list.
> +% Information is collected in several passes.
> +% - If trace_stack_layouts are needed, during the generation of the
> +% procedure's prolog code (in code_gen.m) we add the information
> +% about live values at entry.
> +% - If execution tracing is needed, during the generation of the
> +% procedure's epilog code (in code_gen.m) we add the information
> +% about live values at exit.
These two points should mostly use the same phrases, sentence structure etc
to highlight their differences.
> +% - If basic_stack_layouts are needed, after code for a procedure
> +% has been generated, the proc_layout_general_info is added to
> +% the continuation_info, and some internal label information
> +% is initialized (but not filled in with live values).
> +% - If agc_stack_layouts are needed, after the code has been
> +% optimized a pass is made a pass is made over the final LLDS
> +% instructions. Information about internal labels, is collected.
> +% The liveness information in call instructions is stored with the
> +% corresponding continuation label.
a pass is made a pass is made
> :- type proc_layout_info
> --->
> proc_layout_info(
> + maybe(proc_layout_general_info),
> + map(label, internal_layout_info),
> + % info for each internal label
> + maybe(continuation_label_info), % entry
> + maybe(continuation_label_info) % exit
> + % live data information about
> + % entry and exit points
> + ).
> +
> +:- type proc_layout_general_info
> + --->
> + proc_layout_general_info(
> proc_label, % the proc label
> int, % number of stack slots
> code_model, % which stack is used
> - maybe(int), % location of succip on stack
> - map(label, internal_layout_info)
> - % info for each internal label
> + maybe(int) % location of succip on stack
^ % (if any)
> ).
Why is the proc_layout_general_info inside a maybe?
I presume that the maybe(continuation_label_info) will be yes with tracing
and no otherwise. Please document this.
Similarly that the map of internal_layout_infos will be empty unless you
have agc set.
> -% When using accurate gc, liveness is computed slightly differently.
> -% The garbage collector needs access to the typeinfo variables of any
> -% variable that could be live at a garbage collection point. In the
> -% present design of the garbage collector, garbage collection takes place
> -% at procedure returns.
> +% When using accurate gc or execution tracing, liveness is computed
> +% slightly differently. The runtime system access to the
> +% typeinfo variables of any variable that is live at a continuation.
That sentence is screwed up a bit.
> +stack_layout__construct_agc_rvals(Internal, RvalList) -->
> + stack_layout__get_agc_stack_layout(AgcStackLayout),
> + (
> + { AgcStackLayout = yes }
> + ->
> + { Internal = internal_layout_info(ContinuationLabelInfo) },
> + {
> + ContinuationLabelInfo = yes(continuation_label_info(
> + LiveLvalSet0, TVars0))
> + ->
> + LiveLvalSet = LiveLvalSet0,
> + TVars = TVars0
> + ;
> + % We record no live values here. This might not be
> + % true, however this label is not being used as a
> + % continuation, so it shouldn't be relied upon.
> +
> + set__init(LiveLvalSet),
> + set__init(TVars)
> + },
> + stack_layout__construct_livelval_rvals(LiveLvalSet, TVars,
> + RvalList)
> + ;
> + { RvalList = [yes(const(int_const(0))),
> + yes(const(int_const(0)))] }
> + ).
I know this is old code that was just moved around, but I don't understand it.
The comment doesn't help, since I don't what "it" cannot be relied upon,
and by whom.
The rest looks OK.
Zoltan.