[m-dev.] for review: type specialisation [2]

[Fergus Henderson]

On 30-Aug-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> 
> +++ hlds_data.m	1998/08/12 04:19:21
> @@ -36,12 +36,14 @@
>                          % whereas a code_addr_const is just an address.
>                  ;       base_type_info_const(module_name, string, int)
>                          % module name, type name, type arity
> +                ;       base_typeclass_info_const(module_name,
> +                                class_id, int, string)
>                          % name of module containing instance
> +                        % declaration (not filled in by
> +                        % polymorphism.m - why?), class name and arity,
> +                        % class instance, a string encoding the type
> +                        % names and arities of the arguments to the
> +                        % instance declaration 

Anyone know why the module_name in a base_typeclass_info_const
is not filled in by polymorphism.m?  DJ?

hlds_pred.m:
> @@ -1151,6 +1155,10 @@
>                          map(class_constraint, var),
>                                          % typeclass_info vars for class
>                                          % constraints
> +                                        % Note that this field is not looked
> +                                        % at after polymorphism is run, and
> +                                        % is created by polymorphism, so it
> +                                        % is probably redundant.
>                          eval_method,    % how should the proc be evaluated      
>                          maybe(arg_size_info),
>                                          % Information about the relative sizes

mercury_to_mercury.m:
>  output_type(VarSet, Type) -->
> -        mercury_output_term(Type, VarSet, no).
> +        mercury_output_term(Type, VarSet, yes).

This change (to include variable numbers in the output types)
was not listed in the log message.

I think this change is a good idea in the long term
but in the short term it may cause some inconsistency, because
there are other places which print types without the variable numbers.

> +++ pd_info.m	1998/07/30 03:58:01
> @@ -739,7 +739,9 @@
>          { proc_info_vartypes(ProcInfo, VarTypes) },
>          { proc_info_typeinfo_varmap(ProcInfo, TVarMap) },
>          { proc_info_typeclass_info_varmap(ProcInfo, TCVarMap) },
> -        { hlds_pred__define_new_pred(Goal, CallGoal, Args, InstMap, 
> +        % XXX handle the extra typeinfo arguments for
> +        % --typeinfo-liveness properly.
> +        { hlds_pred__define_new_pred(Goal, CallGoal, Args, _ExtraArgs, InstMap, 
>                  Name, TVarSet, VarTypes, ClassContext, TVarMap, TCVarMap,
>                  VarSet, Markers, ModuleInfo0, ModuleInfo, PredProcId) },
>          pd_info_set_module_info(ModuleInfo).

Hmm, that's a worry.  Should we be disabling --deforestation if
--typeinfo-liveness is specified?

type_util.m:
>  :- pred apply_substitutions_to_var_map_2(list(var)::in, map(tvar,
> -                type_info_locn)::in, tsubst::in, map(var, var)::in, 
> -                map(tvar, type_info_locn)::in, 
> +                type_info_locn)::in, tsubst::in, map(tvar, type)::in,
> +                map(var, var)::in, map(tvar, type_info_locn)::in, 
>                  map(tvar, type_info_locn)::out) is det.
>  
> -apply_substitutions_to_var_map_2([], _VarMap0, _, _, NewVarMap, NewVarMap).
> -apply_substitutions_to_var_map_2([TVar | TVars], VarMap0, TSubst, Subst, 
> -                NewVarMap0, NewVarMap) :-
> +apply_substitutions_to_var_map_2([], _VarMap0, _, _, _, NewVarMap, NewVarMap).
> +apply_substitutions_to_var_map_2([TVar | TVars], VarMap0, TRenaming,
> +                TSubst, VarSubst, NewVarMap0, NewVarMap) :-
>          map__lookup(VarMap0, TVar, Locn),
>          type_info_locn_var(Locn, Var),
> +        
> +                % find the new var, if there is one
> +        ( map__search(VarSubst, Var, NewVar0) ->
> +                NewVar = NewVar0
> +        ;
> +                NewVar = Var
> +        ),
> +        type_info_locn_set_var(Locn, NewVar, NewLocn),
>  
>                  % find the new tvar, if there is one, otherwise just
>                  % create the old var as a type variable.
> -        ( map__search(TSubst, TVar, NewTerm0) ->
> -                NewTerm = NewTerm0 
> +        (
> +                map__search(TRenaming, TVar, NewTVar0)
> +        ->
> +                ( NewTVar0 = term__variable(NewTVar1) ->
> +                        NewTVar2 = NewTVar1
> +                ;
> +                        % varset__merge_subst only returns var->var mappings,
> +                        % never var->term.
> +                        error(
> +                        "apply_substitution_to_var_map_2: weird type renaming")
> +                )
>          ; 
> -                type_util__var(NewTerm, TVar)
> +                % The variable wasn't renamed.
> +                NewTVar2 = TVar
>          ),
>  
> -                % find the new var, if there is one
> -        ( map__search(Subst, Var, NewVar0) ->
> -                NewVar = NewVar0
> +        ( map__search(TSubst, NewTVar2, NewType0) ->
> +                NewType = NewType0
>          ;
> -                NewVar = Var
> +                % The variable wasn't substituted.
> +                type_util__var(NewType, NewTVar2)
>          ),
> -        type_info_locn_set_var(Locn, NewVar, NewLocn),

Should it apply TSubst recursively here?

doc/user_guide.texi:
> + at sp 1
> + at item --higher-order-size-limit
> +Set the maximum goal size of specialized versions created by
> + at samp{--optimize-higher-order} and @samp{--type-specialization}.

It would be helpful to give some indication of the units
(both here and in the help message in options.m).

> @@ -97,6 +98,9 @@
>  # some tests need to be compiled with particular options
>  
>  MCFLAGS-boyer           =       --infer-all
> +MCFLAGS-cut_test        =       -O5

cut_test.m will get tested at -O5 on murlibobo anyway;
is there a particular reason why it is better to test it at -O5
on all architectures rather than testing it at different optimization
levels on the different machines?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.