[m-dev.] question about --num-reserved-objects

[Zoltan Somogyi]

I am working on a change that would remove module- and type-
qualification from local variables in the MLDS. This diff simplifies
a lot of code in the MLDS backend, and leads to a speedup that
I measured at around 2% (though I think in practice it is likely
to be somewhat smaller), but in its current form it does break
--num-reserved-objects.

The default value of --num-reserved-objects is 0, and its documentation
explicitly states that this option is not for general use. My current diff
generates bit-identical output in Java and C# grades compared to the
current compiler, with both using the default 0 reserved objects.
I am pretty that wouldn't be the case if both used a nonzero number
of reserved objects. My question is: does that matter? Should we keep
supporting using reserved object tags? Does anyone use them now,
or see using themselves using them in the future?

Using reserved objects (or reserved numeric addresses) as tags requires
all tests of the *other* tags in the type to test for the reserved tags *first*,
so I don't think that using them is a performance win, though I don't believe
we have measured this in a long time. And it is an implementation detail;
no program should *depend* on using reserved objects.

I can complete the diff either by effectively withdrawing support for
--num-reserved-objects, or by changing the diff to generate bit-identical
Java and C# code with nonzero reserved objects. The first can be done
by either simply commenting out num-reserved-objects (and maybe
num-reserved-addresses)  and its /their documentation, or by adding code
to handle_options.m to report an explicit error message if they have been
set to any nonzero value. (Both would need an entry in NEWS as well).
The second would require adding a new kind of mlds_rval, which is more work.

What do people think?

Zoltan.