[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-25 17:06 --- Actually the loop looks correct and we are not overcounting. We keep stats per pointer ssa-name which we aggregate on its NMT and its aliases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #9 from dberlin at gcc dot gnu dot org 2008-01-25 16:51 --- Subject: Re: [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile. On 25 Jan 2008 16:40:54 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: I think we are also over-counting here - shouldn't we just walk over all NMTs once? Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-25 16:40 ---
So we come along some big points-to sets (and thus MTAG_ALIASES) when doing
for (i = 1; i num_ssa_names; i++)
{
...
tag = pi-name_mem_tag;
EXECUTE_IF_SET_IN_BITMAP (MTAG_ALIASES (tag), 0, j, bj)
{
...
such as NMT.62 with 19034 aliases, and that multiple times (for each pointer
that has this NMT! Which in this testcase are a lot).
I think we are also over-counting here - shouldn't we just walk over all
NMTs once?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-08 12:40 --- Would be nice if someone could analyze this, or at least reconfirm that the problem still exists. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-08 13:35 --- Reconfirmed. Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 23.89 41.6141.61 445943529 0.00 0.00 pointer_map_insert 19.66 75.8534.24 445862120 0.00 0.00 get_mem_sym_stats_for 18.62108.2732.42 446338551 0.00 0.00 uid_decl_map_eq 8.17122.5014.233 4.7449.51 compute_memory_partitions 7.60135.7413.24 457347593 0.00 0.00 bitmap_set_bit 5.71145.69 9.95 449120494 0.00 0.00 htab_find_with_hash 1.98149.14 3.45 446137605 0.00 0.00 referenced_var_lookup 0.56150.11 0.97 2946899 0.00 0.00 pointer_set_insert 0.51151.00 0.89 346720 0.00 0.00 bitmap_and_into 0.48151.84 0.84 2068490 0.00 0.00 bitmap_ior_into 0.46152.64 0.80 42298017 0.00 0.00 bitmap_elt_insert_after 0.39153.32 0.69 137584 0.00 0.00 gimple_default_def 41.600.00 445862120/445943529 get_mem_sym_stats_for [10] [20]23.9 41.610.00 445943529 pointer_map_insert [20] 34.24 41.60 445804196/445862120 compute_memory_partitions [ 7] [10]43.6 34.24 41.60 445862120 get_mem_sym_stats_for [10] and there I at some point analyzed it to the quadratic loop in update_reference_counts. This is really Diegos bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-11-01 15:38:16 |2008-01-08 13:35:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #7 from dnovillo at gcc dot gnu dot org 2008-01-08 14:24 --- Will work on this. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|WAITING |ASSIGNED Last reconfirmed|2008-01-08 13:35:38 |2008-01-08 14:24:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-02 23:46 --- Any news on this bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-01 15:38 --- Confirmed btw. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-01 15:38:16 date|| Summary|[4.3 Regression]Tree memory |[4.3 Regression] Tree memory |partitioning is spending 430|partitioning is spending 430 |seconds of a 490 second |seconds of a 490 second |compile.|compile. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression]Tree memory partitioning is spending 430 seconds of a 490 second compile.
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression]Tree memory partitioning is spending 430 seconds of a 490 second compile.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog Summary|Tree memory partitioning is |[4.3 Regression]Tree memory |spending 430 seconds of a |partitioning is spending 430 |490 second compile. |seconds of a 490 second ||compile. Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/33237] [4.3 Regression]Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-29 20:52 --- I think this comes down to the referenced decls is huge because of the static const variable but I don't know for sure (I had looked into one of those issues before). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
