[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