[m-dev.] for review: Aditi [2]

[Simon Taylor]

> 
> On 07-Jul-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > +:- type aditi_dependency_ordering       == list(aditi_sub_module).
> > +
> > +        % Each Aditi SCC contains one or more SCCs from the original 
> > +        % dependency ordering and the entry points of the SCC.
> > +:- type aditi_sub_module
> > +        --->    aditi_sub_module(dependency_ordering, list(pred_proc_id)).
> 
> The use of the term "sub_module" is confusing now that Mercury
> has nested modules.  I suggest you use "SCC" instead.
> 
> You should document what defines an valid Aditi SCC.

I've copied across the documentation from dependency_graph.m

> > --- hlds_pred.m	1998/05/15 07:07:10	1.48
> > +++ hlds_pred.m	1998/06/04 06:29:24
> > @@ -204,10 +204,47 @@
> > +        ;       memo            % Requests that this predicate be evaluated
> > +                                % using memoing.
> > +        ;       no_memo         % Ensure that this procedure is not memoed.
> 
> Hmm, there's already an eval_method of eval_memo in the proc_info;
> how do these two relate?

I've changed the names to aditi_memo and aditi_no_memo to emphasise that
these are unrelated.

> > +        ;       generate_inline % Used for small procedures which project
> > +                                % a relation to be used as input to a call.
> > +                                % The goal should consist of fail, true
> > +                                % or a single rule.
> > +                                % These relations are never memoed.
> > +                                % The reason these must be generated inline
> > +                                % is to ensure that the relation used for
> > +                                % input is a projection of the current 
> > +                                % value of the projected relation for all
> > +                                % orderings of the SCC.
> 
> I must confess that the justification given here has me mystified.

I've added this comment to magic_util.m where the marker is introduced
(and added a pointer to it from hlds_pred.m):

                % The projecting goal must be generated inline.
                % Otherwise there could be problems with transformed
                % code such as:
                %
                % q(InP, X, Y, Z) :-
                %       magic_p(InP, X, Y),
                %       InR = q_supp1(InP),
                %       r(InR, A, Z),
                %       Y == A.
                % q_supp1(InP, Y) :-
                %       magic_p(InP, _X, Y).
                %
                % 'r/3' is defined in a lower SCC.
                %
                % rl_gen could produce the recursive part of this SCC as:
                %
                % toplabel:
                % if (diffs empty) goto bottomlabel:
                %       evaluate magic_p;
                %       evaluate q;
                %       evaluate q_supp1;
                % goto toplabel;
                % bottomlabel:
                %
                % In this case, if `q_supp1/2' was not generated inline,
                % the input relation for the call to `r/3' in `q/4'
                % would use the value of `magic_p/3' from the previous
                % iteration, but the join of `magic_p/3' and the result
                % of `r/3' uses the value of `magic_p/3' from the
                % current iteration.
                %
                % The generate_inline marker forces rl_gen.m evaluate
                % `q_supp1/2' in the correct location so that it uses
                % the correct version of `magic_p/3' as input to `r/3'.

 
> > Index: compiler/lambda.m
> >                  list__append(ArgModes1, Modes, AllArgModes),
> >                  map__apply_to_list(AllArgVars, VarTypes, ArgTypes),
> >  
> > +                ( 
> > +                        % Pass through the aditi markers for 
> > +                        % aggregate query closures.
> > +                        Detism = nondet,
> > +                        check_marker(Markers, aditi)
> > +                ->
> > +                        LambdaMarkers = Markers
> > +                ;
> > +                        init_markers(LambdaMarkers)
> > +                ),
> 
> Why only `nondet'?  What about `multi', for example?

I've changed that to `determinism_components(Detism, _, at_most_many)'

> 
> > +        % If there are local Aditi procedures enable Aditi compilation.
> > +:- pred maybe_enable_aditi_compilation(item_status, term__context,
> > +                module_info, module_info, io__state, io__state) is det.
> > +:- mode maybe_enable_aditi_compilation(in, in, in, out, di, uo) is det.
> > +
> > +maybe_enable_aditi_compilation(Status, Context, Module0, Module) -->
> > +        { Status = item_status(ItemStatus, _) },
> > +        ( { ItemStatus \= imported } ->
> 
> What about opt_imported predicates?

We may need to generate RL code for opt_imported predicates if they are
specialised. If they are not, they are made imported by dead_proc_elim,
and having aditi compilation enabled will be harmless.

Simon.