This is the mail archive of the
mailing list for the GCC project.
What data are needed for optimizations?
- To: gcc at gcc dot gnu dot org
- Subject: What data are needed for optimizations?
- From: Brad Lucier <lucier at math dot purdue dot edu>
- Date: Mon, 8 Nov 1999 13:22:28 -0500 (EST)
- Cc: lucier at math dot purdue dot edu, feeley at iro dot umontreal dot ca
Jeff's message about optionally computing dominators based on what data
is needed for later optimizations set me thinking---what data are needed
for the optimizations in -O1, or, in fact, for any set of optimizations?
The passes that seem to be called with -O1 -fPIC -mcpu=ev6 -fno-math-errno
time in parse: 15.057728 (10%)
time in jump: 65.426160 (45%)
time in cse: 5.695936 (4%)
time in loop: 0.050752 (0%)
time in flow: 6.109760 (4%)
time in combine: 6.140016 (4%)
time in local-alloc: 3.274480 (2%)
time in global-alloc: 26.542320 (18%)
time in flow2: 6.167344 (4%)
time in shorten-branch: 0.418704 (0%)
time in final: 3.610224 (2%)
time in varconst: 0.002928 (0%)
time in gc: 1.878800 (1%)
What's killing me right now is the size of the jump information computed by
flow.c for my threaded app when that app is implemented using computed
goto's. The question I'd like to as is this---do later passes need any
more information than just whether there is a jump from a given basic
block to another? This could be (and is, for internal purposes) stored
in a simple bit set with about 3003*3003=9018009 entries, or < 1 1/8
megabyte, while the current information takes about 120 Mbytes on the PII.
It would seem that only passes that want to attach code to edges or do
other nasty (and useful) things would need the complete edge information
from the structures defined in basic-block.h.
Is this true? Can later passes with -O1 get by with only the 1 Mbyte
bitmap for the information they need? Can the extra information about
edges be computed only when it's needed for later passes (which presumably
are activated by -O2 or separately with their own flags)?