This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
- From: "Joost.VandeVondele at pci dot uzh.ch" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 9 Jun 2011 06:54:51 +0000
- Subject: [Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
- Auto-submitted: auto-generated
- References: <bug-49310-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310
--- Comment #7 from Joost VandeVondele <Joost.VandeVondele at pci dot uzh.ch> 2011-06-09 06:54:33 UTC ---
two more datapoints (depth=30 is still running):
max-vartrack-expr-depth=22: var-tracking emit :5459.44 (99%) usr
max-vartrack-expr-depth=25: var-tracking emit :42078.07 (100%) usr
these are the timings for the various -Ox
'-g -O0 -fbounds-check' : 14s
'-g -O1 -fbounds-check' : 2631s
' -O1 -fbounds-check' : 44s
'-g -O2 -fbounds-check' : 43s
from this point of view, something at -O2 seems to be very good at cleaning up
these very long expressions very cheaply. Would it make sense to run that pass
also at -O1 (maybe only when these long expressions are observed) ?