[m-rev.] for post-commit review: setting up module_and_imports

Julien Fischer jfischer at opturion.com
Tue May 7 17:10:46 AEST 2019


Hi Zoltan,

On Mon, 6 May 2019, Zoltan Somogyi wrote:

> Like some earlier diffs, this one also adds new code to do the same job
> as old code, checking that their output is the same. If anyone finds
> a compiler abort where this is not the case, please tell me.

I've run this on all my usual test cases and have not encountered any
problems.

> Start moving towards one way to set up module_and_imports.
> 
> At the moment, the compiler has two separate ways to create an initial
> module_and_imports structure.

...


> diff --git a/compiler/prog_item.m b/compiler/prog_item.m
> index d3d43f5..6a0f2f6 100644
> --- a/compiler/prog_item.m
> +++ b/compiler/prog_item.m

...


> @@ -2152,10 +2231,16 @@ get_pragma_foreign_code(Globals, Pragma, !Info) :-
>      globals.get_backend_foreign_languages(Globals, BackendLangs),
>      globals.get_target(Globals, Target),
> 
> -    % The code here should match the way that mlds_to_gcc.m decides whether
> -    % or not to call mlds_to_c.m.
> -    % XXX FIXME mlds_to_gcc.m no longer exists.
>      (
> +        % We do NOT count foreign_decls here. We only link in a foreign object
> +        % file if mlds_to_gcc called mlds_to_c.m to generate it, which it
> +        % will only do if there is some foreign_code, not just foreign_decls.
> +        % Counting foreign_decls here causes problems with intermodule
> +        % optimization.

Something needs updating here (the comment certainly), but I'm not quite
sure what.  Was there an issue with foreign_decls and intermodule
optimization independent of the GCC backend?

Julien.


More information about the reviews mailing list