[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