[m-rev.] for review: fix bug with polymorphic modes and intermodule optimization

[Mark Brown]

On 07-Nov-2005, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:
> Estimated hours taken: 16
> Branches: main
> 
> Fix the problem that has been causing hard_coded/intermod_poly_mode to fail.
> 
> When writing foreign_procs to .opt files, make sure that any inst variables
> have the correct name.

On a related note, the reference manual doesn't appear to say anything about
the scope of inst variables.  Does the scope extend to foreign_proc decls
(like how the scope of type variables extends to clauses), or can we use
different names in the foreign_proc decl?  If the former is the case, then
you should also check that the names in the foreign_proc match those in the
selected mode.

> 
> compiler/add_pragma.m:
> 	When searching for the predmode decl corresponding to a foreign_proc
> 	allow for a renaming between inst variables.  If we don't do this,
> 	then the compiler cannot find the corresponding predmode declaration
> 	for opt_imported foreign_procs that have polymorphically moded
> 	arguments.  (The reason this is occurring is a bit obscure, it it

s/it it/it/

> 	looks like the inst_vars in the predmode decl and those in the
> 	foreign_proc are being allocated from different inst_varsets.  Tracing
> 	this through in the debugger indicates that this happening quite early
> 	on, it may be that we've never made the necessary connection between
> 	the sets of inst variables and we've never used polymorphically moded
> 	procedures extensively enough to notice.)

See my comment below, in mercury_to_mercury.m.

> Index: compiler/add_pragma.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/add_pragma.m,v
> retrieving revision 1.16
> diff -u -r1.16 add_pragma.m
> --- compiler/add_pragma.m	4 Nov 2005 03:40:42 -0000	1.16
> +++ compiler/add_pragma.m	7 Nov 2005 04:03:27 -0000
> @@ -1372,8 +1372,14 @@
>              map__to_assoc_list(Procs, ExistingProcs),
>              pragma_get_modes(PVars, Modes),
>              (
> -                get_procedure_matching_argmodes(ExistingProcs, Modes,
> -                    !.ModuleInfo, ProcId)
> +                % XXX We need to allow for a renaming between inst variables
> +                % here, otherwise we won't find a match for opt_imported
> +                % foreign_procs that have polymorphically moded arguments.
> +                % This occurs because the inst vars in the foreign_proc
> +                % and the corresponding mode declaration seem to be allocated
> +                % from different inst_varsets.
> +                get_procedure_matching_argmodes_with_renaming(ExistingProcs,
> +                    Modes, !.ModuleInfo, ProcId)

Why is this an XXX?  The variables come from different varsets, so it is only
natural that we should have to bind the variables in one context to those in
the other.

> Index: compiler/mercury_to_mercury.m
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/compiler/mercury_to_mercury.m,v
> retrieving revision 1.272
> diff -u -r1.272 mercury_to_mercury.m
> --- compiler/mercury_to_mercury.m	28 Oct 2005 02:10:18 -0000	1.272
> +++ compiler/mercury_to_mercury.m	7 Nov 2005 04:02:15 -0000
> @@ -558,8 +560,10 @@
>      ;
>          Pragma = foreign_proc(Attributes, Pred, PredOrFunc, Vars, VarSet,
>              PragmaCode),
> +        % The inst_varset isn't available to us here.
> +        InstVarset = varset.init,

The varset in the foreign_proc pragma_type, although it is a prog_varset,
appears to contain the names of the inst variables.  When parsing the
foreign_proc declaration we just cast the varset to a prog_varset and that's
it.  Instead, we should handle the varset similarly to the processing of
pred_mode declarations, which also contain two sorts of variables (in this
case, type variables and inst variables).  This will require an extra field
to be added to the foreign_proc functor.

Once you have made that change it should be fine to commit this, but you
should still post the relative diff.

The reason the inst variables get different numbers would be that those from
the predmode decls come from varsets that also held type variables, whereas
those from the foreign_proc decls come from varsets that also held program
variables.  The numbers and relative positions of prog_vars and tvars may
differ.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------