[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