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: computed gotos and memory requirements.


On Tue, Oct 26, 1999 at 02:27:26PM -0500, Brad Lucier wrote:
> By my count in basic-block.h, each edge_def struct
> contains 6 pointers and two ints, or 32 bytes per edge_def on a PII, or 56
> bytes per edge_def on the alpha, so we're talking 117,237,120 bytes for
> this information on the PII, 205,164,960 bytes on the alpha.

That sounds about right.

> Wouldn't it be much more efficient, and give you the same amount
> of useful information, to have one more type of edge information,
> an EDGE_COMPUTED edge, that would point to a single array of possible
> label addresses, with their information stored only once and shared by
> all the EDGE_COMPUTED edges?

I'd rather not have multiple edge structure formats, since that
complicates every place edges are used.

But something similar did occur to me recently.  Instead of representing
edges differently, we create a special CGOTO_BLOCK (index -3) that has
all computed gotos as predecessors and all addressed labels as successors.
In this way we'd prevent the exponential growth of edges.

The tricky part of this approach is that under no circumstances can we
allow any global optimizations to insert instructions in this special
block.  Probably not impossible, but the gcse algorithms are going to
resent such restrictions.


r~


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