[m-rev.] for review: optimization_options.m

[Peter Wang]

On Tue, 29 Sep 2020 12:21:42 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> Make --everything-in-one-c-function a bool option.
> 
> It used to be a special option that just set procs_per_c_function
> to the special value of zero, but this behavior is inconsistent with
> optimization_options taking the max of the old and new values of
> integer options. This meant that --procs-per-c-function=5 -O6
> would not put all procedures into one C function.
> 

> diff --git a/compiler/code_util.m b/compiler/code_util.m
> index ebb2a61f3..9ef548114 100644
> --- a/compiler/code_util.m
> +++ b/compiler/code_util.m
> @@ -36,18 +38,29 @@
>  
>  %-----------------------------------------------------------------------------%
>  
> +:- type for_from_where
> +    --->    for_from_everywhere
> +    ;       for_from_proc(maybe_use_just_one_c_func, pred_id, proc_id).
> +
>      % Create a code address which holds the address of the specified procedure.
> -    % The `immed' argument should be `no' if the caller wants the returned
> -    % address to be valid from everywhere in the program. If being valid from
> -    % within the current procedure is enough, this argument should be `yes'
> -    % wrapped around the value of the --procs-per-c-function option and the
> -    % current procedure id. Using an address that is only valid from within
> -    % the current procedure may make jumps more efficient.
> +    % The `for_from_where' argument should be `for_from_everywhere'
> +    % if the caller wants the returned address to be valid from everywhere
> +    % in the program. If being valid from within a specified procedure
> +    % (the current procedure) is enough, this argument should be
> +    % `for_from_proc' wrapped around the value of the use_just_one_c_func
> +    % option and the current procedure id. Using an address that is
> +    % only valid from within the current procedure may make jumps faster.
> +    %
> +    % Note that we cannot take advantage of situations in which the caller
> +    % and the callee are in the same C module even though use_just_one_c_func
> +    % is not set, because what procedures end up in the same C module
> +    % is decided only long after the LLDS has been constructed.
>      %

Change "even though use_just_one_c_func is not set"
to "even if use_just_one_c_func is unset"?

The rest looks fine.

Peter