This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 May 2008 14:16:08 -0000
- Subject: [Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
- References: <bug-36291-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-23 14:16 -------
Ok, apart from the var annotations I give up here as far as 4.3 is concerned.
We cannot really fix the compile-time problem without skewing the heuristics
and risking fallout through that.
We already know from PR33237 that the algorithmic problem is here:
-: 1252:update_reference_counts (struct mem_ref_stats_d *mem_ref_stats)
6274: 1253:{
...
62908: 1296: if (MTAG_ALIASES (tag))
76443361: 1297: EXECUTE_IF_SET_IN_BITMAP (MTAG_ALIASES (tag), 0, j,
bj)
-: 1298: {
...
due to the high number of referenced vars the aliases tend to be a lot - and
we visit them multiple times as well (but they are not easy to combine).
For trunk the idea could be to exempt call clobbered vars from the
partitioning heuristics completely and simply partition them into a single
partition up-front. (They all end up in the same partition anyway, but in
some cases are of course not partitioned at all - which is where we would
clearly loose without the alias oracle as a fallback)
Micro-optimizing for this testcase is possible, but several attempts only
result in very minor improvements.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291