[m-rev.] for review: effective trace levels
Julien Fischer
jfischer at opturion.com
Sat Apr 30 22:44:49 AEST 2022
On Sat, 30 Apr 2022, Zoltan Somogyi wrote:
> Introduce a new type for effective trace levels.
>
> We have two main notions of trace levels. The first is the global trace level,
> which is set by compiler options, and the second is the effective trace level
> for a given procedure. The two are different not just in that the effective
> trace level for a procedure may differ from the global trace level, but also
> in that there exist effective trace levels that cannot be specified using
> compiler options.
...
> diff --git a/compiler/handle_options.m b/compiler/handle_options.m
> index f7411ad82..678df1293 100644
> --- a/compiler/handle_options.m
> +++ b/compiler/handle_options.m
> @@ -1833,6 +1833,12 @@ handle_debugging_options(Target, TraceLevel, TraceEnabled, SSTraceLevel,
> AllowTraceTailRec = trace_level_allows_tail_rec(TraceLevel),
> (
> AllowTraceTailRec = bool.no,
> + % XXX Any code that checks the exec_trace_tail_rec option
> + % should insted check the effective trace level for whatever
s/insted/instead/
> + % procedure it wants to operate on. However, at the moment,
> + % the only code that looks at this option is mark_tail_calls.m,
> + % which we invoke only in MLDS grades, which do not implement
> + % execution tracing. So this question is moot (for now).
> globals.set_option(exec_trace_tail_rec, bool(no), !Globals)
> ;
> AllowTraceTailRec = bool.yes
That looks fine otherwise.
Julien.
More information about the reviews
mailing list