[m-rev.] for review: Implement unify/compare of tuples in Mercury.

Peter Wang novalazy at gmail.com
Mon Jul 7 17:58:27 AEST 2014


On Mon, 7 Jul 2014 17:39:56 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi Peter,
> 
> I haven't had time to review this fully, but there's one rather obvious
> thing wrong with.  In principle the change is fine by me -- can you now
> deep profile prince?

Yes (not heavily tested).

> On Mon, 7 Jul 2014, Peter Wang wrote:
> 
> > Branches: master
> >
> > The hand-written C unify and compare predicates for tuples did not preserve
> > deep profiler invariants correctly across the recursive unify/compare of
> > tuple arguments.  I tried to do so, and failed.  Instead, implement the
> > predicates in Mercury so the compiler can perform the deep profiling
> > transformation on them.  Bug #3.
> >
> > A micro-benchmark on my machine is about twice as fast in asm_fast.gc
> > after this patch, and equally fast in hlc.gc.  The change to the
> > high-level C backend is only to reduce code duplication.
> >
> > I seem to have hit an unrelated bug in compare_representation so I did
> > not implement the compare_representation predicate for tuples yet.
> >
> > library/builtin.m:
> > 	Add `unify_tuple' and `compare_tuple' predicates.
> >
> > 	Add module initialisation predicate which sets
> > 	`MR_special_pred_hooks' to point to those predicates.
> 
> That won't work.  You need to ensure that they are registered *before*
> any user code (such as module local initialisers) can be called.  So the
> right way to do it is as part of io.init_state.

Oh, right.

Perhaps there should be an overall library initialiser in library.m
which then calls initialisers in builtin.m and io.m?

Peter



More information about the reviews mailing list