Re: Size of graphs in conventional compilers

ryer@harp.camb.inmet.com (Mike Ryer) writes:


> Pinku Surana <pinkus@comm.mot.com> wrote:
> > What is, approximately, the size of the flow graphs created by
> > compilers with respect to the parse tree, or to the size of the input
> > program? Does the time taken to create the graphs dominate most uses
> > of the graph?
>
> 500 to 1000 bytes per source line of code is common for full-up graph
> representations of programs. It could be less, but once you have a
> graph, everyone wants to hang their favorite data off it.


I like to use a graph IR, but one that is very lite: around 100-200 bytes
per source line. Big IRs _do_ eat time.




> Creating and hauling the graphs around is likely to account for the
> majority of time in the compiler.


For my compilers, parsing and certain optimizations (e.g., register
allocation) take the majority of the time. Building the graph is way far
down in the time-eater catagories.




> These comments are based on experience with several generations of Ada
> and C compilers. (Newer compilers are *less* graph oriented). Your
> milage will vary.


Again, my compilers are *more* graph oriented: the program is a graph and
there are no other data structures (well, almost ;-).


I think the difference comes from 2 parts philosophy and 1 part
engineering: if you are willing to think of the program as a graph, then
there's lots of bits from a traditional compiler that you can just drop.
When you push this to the edge (in the "less is more" catagory), you get a
light fast compiler, but one that needs more careful engineering.


Cliff
--
Cliff Click Compiler Researcher & Designer
RISC Software, Motorola PowerPC Compilers
cliffc@risc.sps.mot.com (512) 891-7240
--

Return to the comp.compilers page.
Search the comp.compilers archives again.