This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/13776] [tree-ssa] Many C++ compile-time regression in 3.5-tree-ssa 040120
- From: "rguenth at tat dot physik dot uni-tuebingen dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Mar 2004 12:10:41 -0000
- Subject: [Bug c++/13776] [tree-ssa] Many C++ compile-time regression in 3.5-tree-ssa 040120
- References: <20040120183908.13776.kgardas@objectsecurity.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-03-14 12:10 -------
Subject: Re: [tree-ssa] Many C++ compile-time regression in
3.5-tree-ssa 040120
dberlin at gcc dot gnu dot org wrote:
> ------- Additional Comments From dberlin at gcc dot gnu dot org 2004-03-14 04:47 -------
> There are about 100 functions here with > a couple thousand bb's.
> PRE takes about 2-3 seconds for each of these functions.
> Which means i have to microoptimize it in order to get rid of the cumulative time effect.
> A lot of is it simply iterating over large lists looking for certain types of nodes (like EPHiS), where the
> lists are O(n_basic_blocks), and we only need to look at 10 entries or so. This doesn't matter when the
> numbers are close, but when you have 8000 bb's to walk 20 times, instead of walking 40 entries 20
> times, it matters.
Yes. I suppose simply storing those nodes separate does not work, as
does using a hash-table for storing them, no?
Another way would be to reduce the number of bb's somehow? I cannot
think of how 8000 bb's can accumulate in one of my math kernels other
than by inlining and maybe loop header copying. Can't we merge some
bb's before doing PRE?
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776