[m-dev.] --num-reserved-addresses

[Zoltan Somogyi]

It controls how many small integers we can use to represent constants
in grades that do not use primary tags (which in practice means only
the Java and C# grades).

Would anyone object if I deleted this option?

The default value has long been 0, it is never set automatically to anything
else, and I don't remember seeing set to anything else manually either.

The advantages from deleting it would be 

- doing so would simplify the code deciding type representations, and
- we would be able to do away completely with shared_with_reserved_addresses(...)
  tags. Such tags complicate code generation for unifications and for switches,
  and the code we generate for them is slower than it would be in the absence
  of reserved addresses.

The disadvantage is loss of the ability to do so in the future.

Any opinions? Does anyone have any hard data (as opposed to the informed
guess above) about the performance effects of using such reserved addresses,
current or historical?

BTW, I am committing a related diff that deletes the --num-reserved-objects
option (on which we agreed late last year) and the --unboxed-enums option
(which is never set to "no", as far as I can tell).

Zoltan.