This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/13776] [tree-ssa] Many C++ compile-time regression in 3.5-tree-ssa 040120


------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]