Refactor '%live' and '%def' annotations

The annotations in the optimizing passes currently looks like this:

    {'%live',NumRegistersUsed,RegistersUsedBitmap}
    {'%def',RegistersDefinedBitmap}

(NumRegistersUsed is no longer used.)

When I attempted to extend some optimizations, I found that I had to
add additional clauses to tolerate/handle both types of
annotations. That problem would only get worse if any more annotations
are added in the future.

To simplify annotation handling, this commit wraps both types of
annotations in a {'%anno',_} tuple:

    {'%anno',{used,RegistersUsedBitmap}}
    {'%anno',{def,RegistersDefinedBitmap}}

The '%live' annotation has been renamed to 'used' to make it somewhat
clearer what it means, and the unused NumRegistersUsed part of the
old annotation has been removed.

Alternatives considered: My first attempt was to wrap the annotation
in a 'set' tuple so that there would only be 'set' tuples in a block.
For example:

    {set,[],[],{anno,{live,RegistersUsedBitmap}}}

It was not as convenient as expected. Annotations often need to be
handled specially from other instructions in a block. When they are
wrapped in a 'set' tuple, they can very easily be handled incorrectly
or passed on to the next pass. That causes subtle errors or worse
code, and it can be difficult to debug.

Therefore, my conclusion is that annotations should be distinct from
other instructions, to make it obvious when one have missed to handle
an annotation.

0 files changed, 0 insertions, 0 deletions