[m-rev.] for post-commit review: expand the work of --errorcheck-only

Julien Fischer jfischer at opturion.com
Sat Dec 14 16:49:14 AEDT 2024


On Sat, 14 Dec 2024 at 05:40, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
> For review by anyone. The diff is with -b.

> Extend --errorcheck-only to some middle passes.

...

> diff --git a/compiler/mercury_compile_middle_passes.m b/compiler/mercury_compile_middle_passes.m
> index 50aa45ca5..826c7379a 100644
> --- a/compiler/mercury_compile_middle_passes.m
> +++ b/compiler/mercury_compile_middle_passes.m

...

> @@ -130,7 +132,9 @@
>
>  %---------------------------------------------------------------------------%
>
> -middle_pass(ProgressStream, ErrorStream, !HLDS, !DumpInfo, !Specs, !IO) :-
> +middle_pass(ProgressStream, ErrorStream, OpModeFrontAndMiddle,
> +        !HLDS, !DumpInfo, !.Specs, Specs, !IO) :-
> +
>      module_info_get_globals(!.HLDS, Globals),
>      globals.lookup_bool_option(Globals, verbose, Verbose),
>      globals.lookup_bool_option(Globals, statistics, Stats),
> @@ -297,11 +301,38 @@ middle_pass(ProgressStream, ErrorStream, !HLDS, !DumpInfo, !Specs, !IO) :-
>      maybe_dump_hlds(ProgressStream, !.HLDS, 213, "float_reg_wrapper",
>          !DumpInfo, !IO),
>
> -    % If we are compiling in a deep profiling grade then now rerun simplify.
> -    % The reason for doing this now is that we want to take advantage of any
> -    % opportunities the other optimizations have provided for constant
> -    % propagation and we cannot do that once the term-size profiling or deep
> -    % profiling transformations have been applied.
> +    % With OpModeFrontAndMiddle = opfam_errorcheck_only, if may make sense

s/if/it/

> +    % to execute only those passes in the middle end that can report errors.
> +    % However, some passes that cannot return new error_specs may nevertheless
> +    % be needed. They may be needed
> +    %
> +    % - because they establish invariants that later middle end passes
> +    %   depend on, or
> +    %
> +    % - because the changes they make to the HLDS affect the diagnostics
> +    %   that later passes would generate.
> +    %
> +    % The pass that expands out all lambda goals is an example of the former,
> +    % while the pass that expands out HLDS equivalence types is an example
> +    % of the latter.
> +    %
> +    % What we can do is stop after the last middle end pass that can generate
> +    % diagnostics, so that is what we do.
> +    Specs = !.Specs,

That looks fine otherwise.

Julien.


More information about the reviews mailing list