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

[Julien Fischer]

On Mon, 7 Jul 2014, Peter Wang wrote:

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

But working (i.e. you have a profile you can browse), presumably?

>> 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?

io.init_state is effectively the overall library initialiser.

An alternative approach would be to modify mkinit to set hooks directly.

Cheers,
Julien.