Re: on non-rtl function info

[Jeffrey A Law <law at cygnus dot com>]

  In message <19981009171020.C17379@dot.cygnus.com>you write:
  > 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.
Yup.  I find myself calling compute_preds_succs an awful lot.


  > 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.
Yup.


  > 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.
That may be OK short term, but long term we should be thinking about using
data structures that we can update on the fly or incrementally at the end
of a pass.

Or, for some structures, we should just avoid screwing them up :-)  This
applies to SSA for example.  It'd be nice to translate into SSA form, do
a *series* of optimizations, then translate back to normal form.


  > 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.
Tough given our existing data structures (simple arrays and bitmaps).  I guess
using virtual arrays and the growable bitmaps would help.  Or getting away
from depending on block #s :-)  

  >   * 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. 
At one time I wanted to go away from edge lists and rely on the pred/succ info,
but for certain things, edge lists are so much better :-)  For example, using
edge lists allows us to much more easily partition a cfg and compute properties
for the partition.

This is particularly useful if the cfg as a whole is irregular, but has regular
components.   By partitioning the cfg we can perform "global" optimizations
on the components which are regular (making conservative assumptions for
edges which leave the partition).

We should probably take the edge list code out of haifa and put it into
flow.c.  Why recreate code to build edge lists.

Similarly for the code in haifa to find natural loops.


jeff