This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: representing noreturns and traps in the CFG


Hi,

On Fri, 13 Jul 2001, Richard Henderson wrote:

> On Fri, Jul 13, 2001 at 02:16:21PM +0200, Jan Hubicka wrote:
> > But overall, does the idea of adding these extra blocks sound sane?
>
> Um, no.  I can't imagine how they would help.

They would be the place to connect all "dangling" edges to, factored to
the type of dangling.  So we would only have a constant set of tree roots
for the reverse graph.  Nevertheless the same can be accomplished by
creating impossible edges from those border blocks to EXIT_BLOCK.  This
all is needed when one needs the concept of "all paths away from a block",
which traditionally is translated to "all paths from block to EXIT".
Currently e.g. noreturn blocks have no out edges, which leads to
irregularities in the out-path set for each block having a path to such
one (one (possibly empty) subset all ending in EXIT, the rest ending
nowhere or better said in that noreturn block, but for infinite loops
thats different).  For this we need a common end, or a finite set of ends
for paths.

Honza: I don't know what exactly you need, but I guess it would be better
to create impossible edges from those blocks to EXIT, instead of creating
more ending blocks.  This should do mostly the right thing.  Impossible
edges are edges which are not executed, so any insns inserted on them can
be ignored.  If collecting information from successor blocks thru
impossible edges one needs to be careful, only when the successors is
EXIT, that information can be copied.  I'm not sure, but edges with the
EDGE_FAKE bit set look almost like impossible edges.


Ciao,
Michael.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]