[m-rev.] for post-commit review: describe how to parallelize --generate-dependencies-ints

Julien Fischer jfischer at opturion.com
Sat Nov 4 16:36:51 AEDT 2023


On Sat, 4 Nov 2023, Zoltan Somogyi wrote:

> Describe how to parallelize --generate-dependencies-ints.
> diff --git a/compiler/mercury_compile_main.m b/compiler/mercury_compile_main.m
> index ce673866f..3dba3f6c0 100644
> --- a/compiler/mercury_compile_main.m
> +++ b/compiler/mercury_compile_main.m

...

> @@ -1271,6 +1281,28 @@ deps_make_ints(ProgressStream, Globals, DepsMap,
>          Errors3 = no,
>          list.sort(Ancestors, SortedAncestors),
>          assoc_list.values(SortedAncestors, AncestorBurdenedModules),
> +        % XXX This code could be parallelized by the same method as proposed
> +        % for .int3 files above, starting with a !HaveParseTreeMaps
> +        % containing the parse trees of all the .int3 files generated above.
> +        %
> +        % There is a complication, but it does not need a change in code.
> +        %
> +        % The complication is that the process of generating a .int0 file
> +        % for mod_a.mod_b.mod_c.m requires access to the parse trees of
> +        % for mod_a.int0 and mod_a.mod_b.int0. In our context, this means that
> +        % we should not invoke generate_parse_tree_int0 for a module
> +        % until we have already generated the parse trees of all its
> +        % ancestors (if any). The reason why this does not need any extra code
> +        % is the call to list.sort above. Ancestors is an assoc_list,
> +        % but each of its keys is unique, so the sort of the assoc_list
> +        % effectively sorts only on the keys. Each key is the list of
> +        % the module qualifiers in front of the base module name, followed
> +        % by the base module name. Since the empty lists sorts before
> +        % any nonempty list, any comparison of a list of module name components
> +        % (representing an arbitrary module name) with any initial subsequence
> +        % of those components (representing the arbitrary module's anccestors)

s/anccestors/ancestors/

> +        % will put the latter first, thus guaranteeing that we process
> +        % ancestor modules before their descendants.
>          list.map2_foldl2(
>              generate_and_write_interface_file_int0(ProgressStream, Globals,
>                  do_add_new_to_hptm),

Julien.


More information about the reviews mailing list