[m-rev.] for post-commit review: push goals in implicit_parallelism.m

[Paul Bone]

On Wed, Jan 05, 2011 at 03:13:35PM +1100, Zoltan Somogyi wrote:
> On 05-Jan-2011, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > > +    proc_info_get_rtti_varmaps(!.ProcInfo, RttiVarMaps0),
> > > +    PushInfo = push_info(RttiVarMaps0),
> > > +    do_push_list(PushGoals, PushInfo, OverallResult, Goal0, Goal1),
> > > +    (
> > > +        OverallResult = push_failed
> > 
> > So if one push fails we throw away Goal1 thereby rejecting all of the pushes.
> > We may still be able to keep Goal1 and apply some of the automatic
> > parallelisations (but probably not all of them).
> 
> For now, I expect the average number of pushes per predicate to be 1.00001,
> so it does not really matter.

True,

> > As above, we should probably try the remaining pushes incase they allow some
> > more parallelisation.
> 
> It is trivial to do the remaining pushes, but not as trivial to figure out
> which parallelisation transformations planned by the tool are still valid,
> or how their goal paths need to be adjusted. Do after the paper deadline.

Yep.

> > > +is_pushable_goal(PushInfo, Goal, Pushable) :-
> > > +    Goal = hlds_goal(GoalExpr, GoalInfo),
> > > +    Purity = goal_info_get_purity(GoalInfo),
> > > +    Detism = goal_info_get_determinism(GoalInfo),
> > > +    (
> > > +        Purity = purity_pure,
> > > +        Detism = detism_det
> > 
> > How about cc_mutli?
> 
> I haven't thought that through yet, and I don't think there is need for it,
> at least not yet.

Okay.

> > > +                % If ConjNum specifies a conjunct that is NOT the last
> > > +                % conjunct, then this transformation reorders the code.
> > > +                % For now, we don't allow that.
> > > +                list.length(Conjuncts0, Length),
> > > +                ConjNum = Length
> > 
> > This can also be worked around by picking up and moving all the conjuncts after
> > the one that we're pusing into and prepending them to LoHi creating a new LoHi.
> 
> It could be. If it turn out to be a problem, I will change the code.
> In the meantime, I added a comment.

Thanks.

> > Allowing re-ordering is probably better in many cases.
> 
> Testing whether that is safe is easy. Testing whether it is a good idea
> is probably significantly harder.

It's this 'harder' that makes it interesting if we want to look into it later.

The new diff is fine.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20110105/456644ca/attachment.sig>