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

[Julien Fischer]

On Wed, 9 Jul 2014, Peter Wang wrote:

> Hi Julien,
>
> On Tue, 8 Jul 2014 16:26:41 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> 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 doubt there is much performance critical code about that uses tuples
>> anyway.
>
> Right, though they may show up as keys to maps.

True.   FWIW, neither the Mercury compiler or G12 system have any such
maps and I expect them to be very rare in general, since there's a
reasonably strong argument for replacing such tuples by d.u. types
anyway.

>>> +
>>> +typedef struct MR_SpecialPredHooks_Struct {
>>> +  #ifdef MR_HIGHLEVEL_CODE
>>> +    MR_bool     (*MR_unify_tuple_pred)(MR_Word ti, MR_Word x, MR_Word y);
>>> +    MR_bool     (*MR_compare_tuple_pred)(MR_Word ti, MR_Word *res,
>>> +                    MR_Word x, MR_Word y);
>>> +  #else
>>> +    MR_ProcAddr MR_unify_tuple_pred;
>>> +    MR_ProcAddr MR_compare_tuple_pred;
>>> +  #endif
>>> +} MR_SpecialPredHooks;
>>> +
>>> +extern MR_SpecialPredHooks  MR_special_pred_hooks;
>>> +
>>> #endif	/* not MERCURY_HO_CALL_H */
>>> diff --git a/runtime/mercury_unify_compare_body.h b/runtime/mercury_unify_compare_body.h
>>> index 08c3941..dfbaedb 100644
>>
>> The change looks fine to me (modulo my remarks elsewhere in this thread
>> about library initialisation).
>
> I moved the overall initialisation into library.m.  Interdiff follows.
> Let me know if it's okay.

...

The only thing I would change is to add the prefix "std_" the names of
the new library initialisation and finalization predicates (incl. their
exported names).

Cheers,
Julien.