[m-rev.] for review: dependent parallel conjunctions (1/2)

Julien Fischer juliensf at cs.mu.OZ.AU
Mon Jun 26 10:57:20 AEST 2006


On Sun, 25 Jun 2006, Peter Wang wrote:

> > > +    % Transforming the parallel conjunction.
> > > +    %
> > > +    % As a simple first step, all we do is insert waits and signals directly
> > > +    % into the conjunction.  If a conjunct produces a shared variable we turn
> > > +    % that conjunct into a sequential conjunction:
> > > +    %
> > > +    %   prod(Y)  ==>  ( prod(Y), impure signal(PrY, Y) )
> > > +    %
> > > +    % If the conjunct consumes a shared variable we will turn that conjunct
> > > +    % into a sequential conjunction:
> > > +    %
> > > +    %   consume(Y)  ==>  ( wait(PrY, Y), consume(Y) )
> > > +    %
> >
> > I think it would be worth documenting the transformtion for an actual
> > conjunction as well as specifying the transformation for individual conjuncts.
>
> Not sure what you mean.

What I meant was give an example of how the above transformations are
applied to an actual parallel conjunction, e.g.

           a(X::out) & b(X::in) ==>
		(a(X), impure signal(PrX, X)) & (wait(PrX, X), b(X))

> > > +    % References to shared variables need to be renamed apart so that the
> > > +    % conjuncts only share promises.
> > > +    %
> > > +:- pred transform_conjunction(module_info::in, set(prog_var)::in,
> > > +    hlds_goals::in, hlds_goal_info::in, hlds_goal::out, instmap::in,
> > > +    prog_varset::in, prog_varset::out, vartypes::in, vartypes::out) is det.
> > > +
> > > +transform_conjunction(ModuleInfo, SharedVars, Goals, GoalInfo, NewGoal,
> > > +        InstMap, !VarSet, !VarTypes) :-
> > > +    allocate_promises(ModuleInfo, SharedVars, !VarTypes, !VarSet,
> > > +        AllocatePromises, PromiseMap),
> > > +    list.map_foldl3(transform_conjunct(ModuleInfo, SharedVars, PromiseMap),
> > > +        Goals, NewGoals, InstMap, _, !VarSet, !VarTypes),
> > > +    % XXX not sure about GoalInfo
> >
> > What are you not sure about the GoalInfo?
>
> Looking at it again it does seem ok, but I'm never sure about GoalInfos.

Won't the addition of the signal goals have changed the purity of some of the
conjuncts? In which case the goal_features will need updating?

> > > @@ -2431,6 +2432,9 @@
> > >
> > >      maybe_structure_reuse_analysis(Verbose, Stats, !HLDS, !IO),
> > >      maybe_dump_hlds(!.HLDS, 212, "structure_reuse", !DumpInfo, !IO),
> > > +
> > > +    maybe_dependent_par_conj(Verbose, Stats, !HLDS, !IO),
> > > +    maybe_dump_hlds(!.HLDS, 214, "dependent_par_conj", !DumpInfo, !IO),
> >
> > Is this the right spot for this?  Can it be performed any earlier or must it
> > be done here?
> >
> > (Note: this occurs well after inlining so none of the calls to the service
> > predicates in par_builtin will be inlined.  At this stage I don't think it's
> > important, but you add a comment at the top of dep_par_conj.m that it should
> > be looked at again in the future.)
>
> I'm not sure where it should be.  Zoltan suggested I put it fairly late.
> But it's true that the primitives really should be inlined.

At the moment inlining the primitives probably isn't a huge concern.  If need
be it can be handled the same way we do it for tabling and (hl*) trailing,
i.e. by generating foreign_procs inline.

Julien.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the reviews mailing list