on non-rtl function info

[Richard Henderson]

This note is inspired by two things:

One, the general issue of how to sanely manage non-rtl program info
between the passes of the compiler.  This becomes more important when
more global optimization passes are written, so that we'd like to 
reuse things like the pred/succ flow graph, dominators, local and 
global live/dead reg info.  Assuming such info wasn't killed by the
pass, of course.

Two, the fact that flow doesn't preserve a lot information that it ought
or in ways that are usable to other parts of the compiler.  This I ran
into last night with some bits I'm working on -- it turned out that it
was going to be much more work than I thought it ought to be to split
a critical edge.

On the subject of the first, I'm not sure what is the best thing to do.
Something that came to mind was having documented global stores of such
information.  Each passes would record when something it does kills the
information, and each pass would begin with assertions that verify that
the required info is still live, possibly regenerating it if not.

My thought here was a global variable to accompany each documented
structure (e.g. valid_local_life_info) that could easily be set to
false somewhere deep in the bowels of a pass when it knew that it
would not be reliably updating the structures.  This has an
advantage over flagging invalidity by deallocation in that the info
may still be usable within the pass.  And a global variable mirrors
how it is likely any one pass would be forced to signal deallocation
at the end of the pass anyway; making this explicit means we have one
flag variable instead of five.

On the subject of the second, I would like several things:

  * Basic block numbers that are stable from one pass to another
    in the face of shifting blocks, new blocks, etc.  If not the
    block number, then some other stable form of identification.

  * An edge list that records all sorts of little factoids about
    the edge -- properties like `critical' and `abnormal' and
    `probability' leap to mind, though there are others I'd
    thought about. 

    Given that flow has to compute most of these anyway in the
    course of doing its job, it should be no effort at all to
    set a bit in the meantime.  And it seems all too likely that
    having this be more structured would clean up flow at the
    same time.

I'll probably prototype something for this over the next couple of
days, since I'll not be able to make any more progress elsewhere
until its done.

Comments?


r~