[m-dev.] for review: cleanup of type_ctor_infos, relative diff 1

Zoltan Somogyi zs at cs.mu.OZ.AU
Fri Mar 10 16:01:02 AEDT 2000


On 09-Mar-2000, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> If you are going to ignore high numbered arguments, the last bit should
> be set to 1 if there are contains_var_bit_vector_size arguments or more. 
> 
> So there should be contains_var_bit_vector_size - 1 bits that correspond 
> to "ground" or "non-ground" and one bit that says 
> "there are more arugments that must be tested individually".
> 
> If you do it the way you have currently, someone will end up writing
> incorrect code that does:
> 
> 	if (bitvector == 0) {
> 		special case code that doesn't do any variable
> 		substitutions
> 	}

That is just a bug. The optimization *is* already possible, you just have
to call the MR_any_arg_type_may_contain_var macro, which already contains
the correct test: arity <= 16 && bitvector == 0.

Using the last bit as a marker that, if set, says "there are more arguments"
 is not useful, because the functor_desc already contains the arity.

However, using the last bit as a marker that, if set, says that at least one
of the arguments from contains_var_bit_vector_size - 1 to arity - 1 (numbering
arguments from zero) is not ground is a good idea. Here are the new macros:

#define MR_arg_has_own_contain_var_bit(arg_num)                              \
        ((arg_num) < MR_ARG_TYPE_CONTAINS_VAR_BIT_VECTOR_SIZE - 1)

#define MR_initial_arg_type_may_contain_var(functor_desc, arg_num)           \
        (((functor_desc)->MR_du_functor_arg_type_contains_var &              \
                (1 << (arg_num))) != 0)

#define MR_later_arg_type_may_contain_var(functor_desc)                      \
        (((functor_desc)->MR_du_functor_arg_type_contains_var &              \
                (1 << (MR_ARG_TYPE_CONTAINS_VAR_BIT_VECTOR_SIZE - 1))) != 0)

And the test for using them:

            for (i = 0; i < arity; i++) {
                if (MR_arg_has_own_contain_var_bit(i) ?
                    MR_initial_arg_type_may_contain_var(functor_desc, i) :
                    MR_later_arg_type_may_contain_var(functor_desc))
                {
                    ...

This is not any more expensive for the first 15 args than the test I had
initially implemented. For later args, it is more expensive by a bit vector
lookup, but has a chance of avoiding a type_info creation, so it is worth it;
it is being bootchecked now.

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list