public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory @ 2006-12-06 17:15 rguenth at gcc dot gnu dot org 2006-12-06 17:17 ` [Bug tree-optimization/30089] " rguenth at gcc dot gnu dot org ` (24 more replies) 0 siblings, 25 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2006-12-06 17:15 UTC (permalink / raw) To: gcc-bugs Two testcases will follow, build with -O2. -- Summary: Compiling FreeFem3d uses unreasonable amount of time and memory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: memory-hog, compile-time-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org @ 2006-12-06 17:17 ` rguenth at gcc dot gnu dot org 2006-12-06 17:19 ` rguenth at gcc dot gnu dot org ` (23 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2006-12-06 17:17 UTC (permalink / raw) To: gcc-bugs ------- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-06 17:17 ------- Created an attachment (id=12758) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12758&action=view) first testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org 2006-12-06 17:17 ` [Bug tree-optimization/30089] " rguenth at gcc dot gnu dot org @ 2006-12-06 17:19 ` rguenth at gcc dot gnu dot org 2006-12-06 17:20 ` rguenth at gcc dot gnu dot org ` (22 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2006-12-06 17:19 UTC (permalink / raw) To: gcc-bugs ------- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-06 17:18 ------- Created an attachment (id=12759) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12759&action=view) second testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org 2006-12-06 17:17 ` [Bug tree-optimization/30089] " rguenth at gcc dot gnu dot org 2006-12-06 17:19 ` rguenth at gcc dot gnu dot org @ 2006-12-06 17:20 ` rguenth at gcc dot gnu dot org 2006-12-07 4:48 ` dberlin at gcc dot gnu dot org ` (21 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2006-12-06 17:20 UTC (permalink / raw) To: gcc-bugs ------- Comment #3 from rguenth at gcc dot gnu dot org 2006-12-06 17:20 ------- Before the last big regressions on the mainline the first one took 350MB and 52s to build with -O2 on x86_64, the second one 685MB and 147s. That was g++ (GCC) 4.3.0 20061122 (experimental). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (2 preceding siblings ...) 2006-12-06 17:20 ` rguenth at gcc dot gnu dot org @ 2006-12-07 4:48 ` dberlin at gcc dot gnu dot org 2006-12-07 12:41 ` rguenth at gcc dot gnu dot org ` (20 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dberlin at gcc dot gnu dot org @ 2006-12-07 4:48 UTC (permalink / raw) To: gcc-bugs ------- Comment #4 from dberlin at gcc dot gnu dot org 2006-12-07 04:48 ------- On my machine, with an unoptimized cc1plus (IE stage1), the first one, at -O2 takes 150meg of memory total, and 221 seconds, with most of the time being verifiers. This is with local PTA changes to speed up PTA TOTAL : 221.58 17.76 271.63 note: tree SSA verifier : 51.90 (23%) usr 0.89 ( 5%) sys 56.19 (21%) wall 74 kB ( 0%) ggc tree STMT verifier : 40.15 (18%) usr 0.88 ( 5%) sys 41.12 (15%) wall etc The *other* case is spending all it's alias time checking for dups in add_may_alias, which diego's patch should fix. There is also a ton of time elsewhere: tree alias analysis : 71.28 (21%) usr 1.66 ( 9%) sys 114.75 (26%) wall 18776 kB ( 5%) ggc tree SSA verifier : 33.40 (10%) usr 0.43 ( 2%) sys 34.55 ( 8%) wall 259 kB ( 0%) ggc tree STMT verifier : 30.43 ( 9%) usr 0.64 ( 3%) sys 31.04 ( 7%) wall 0 kB ( 0%) ggc PRE : 64.49 (19%) usr 0.64 ( 3%) sys 75.84 (17%) wall 1086 kB ( 0%) ggc scheduling 2 : 46.21 (14%) usr 0.35 ( 2%) sys 62.71 (14%) wall 2328 kB ( 1%) ggc TOTAL : 339.09 19.05 444.66 (it was in a debugger for about 100s to get some idea of what was going on). But on my machine, it still only uses 350 meg of memory On x86_64, i expect about double memory usage. I also expect if i tested bootstrapped optimized compilers, i'd get the same times you are expecting, excluding checking time This leaves a few possibilities: 1 My local PTA improvements are helping this 2 Something is very different on x86_64 3 My preprocessing using Apple G++ 4.0.1 is giving very different code to play with than mainline does 4 The regression is already fixed :) I can either send you the patch to test for 1, or you can wait a few days for me to commit it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (3 preceding siblings ...) 2006-12-07 4:48 ` dberlin at gcc dot gnu dot org @ 2006-12-07 12:41 ` rguenth at gcc dot gnu dot org 2006-12-07 14:07 ` rguenth at gcc dot gnu dot org ` (19 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2006-12-07 12:41 UTC (permalink / raw) To: gcc-bugs ------- Comment #5 from rguenth at gcc dot gnu dot org 2006-12-07 12:40 ------- Numbers with mainline r119612 are FiniteElementMethod.cpp: 346MB, 46.86s parse.ff.cc: 1GB, 1236.53s so actually the latter is the biggest offender here ;) The compiler was built with release checking (but not bootstrapped, built with gcc 4.1.2). Flags for building parse.ff.cc are -O2 -fno-strict-aliasing (in case this makes a difference). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (4 preceding siblings ...) 2006-12-07 12:41 ` rguenth at gcc dot gnu dot org @ 2006-12-07 14:07 ` rguenth at gcc dot gnu dot org 2006-12-12 16:44 ` rguenth at gcc dot gnu dot org ` (18 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2006-12-07 14:07 UTC (permalink / raw) To: gcc-bugs ------- Comment #6 from rguenth at gcc dot gnu dot org 2006-12-07 14:07 ------- tree alias analysis :1125.41 (91%) usr 1.57 (31%) sys1127.32 (91%) wall 199468 kB (19%) ggc PRE : 61.16 ( 5%) usr 0.83 (16%) sys 62.01 ( 5%) wall 2073 kB ( 0%) ggc TOTAL :1239.40 5.05 1244.82 1038165 kB So, easy whom to blame ;) -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dberlin at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (5 preceding siblings ...) 2006-12-07 14:07 ` rguenth at gcc dot gnu dot org @ 2006-12-12 16:44 ` rguenth at gcc dot gnu dot org 2006-12-13 17:32 ` dnovillo at gcc dot gnu dot org ` (17 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2006-12-12 16:44 UTC (permalink / raw) To: gcc-bugs ------- Comment #7 from rguenth at gcc dot gnu dot org 2006-12-12 16:44 ------- We're now ICEing in internal compiler error: in ssa_operand_alloc, at tree-ssa-operands.c:365 for the second testcase. -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|unassigned at gcc dot gnu |dnovillo at redhat dot com |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (6 preceding siblings ...) 2006-12-12 16:44 ` rguenth at gcc dot gnu dot org @ 2006-12-13 17:32 ` dnovillo at gcc dot gnu dot org 2006-12-13 23:50 ` dnovillo at gcc dot gnu dot org ` (16 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dnovillo at gcc dot gnu dot org @ 2006-12-13 17:32 UTC (permalink / raw) To: gcc-bugs ------- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:32 ------- http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00959.html fixes the ICE in the operand scanner. The alias times should be back to saner values, but the memory consumption problem is still there. Still looking into that. -- dnovillo at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|dnovillo at redhat dot com |dnovillo at gcc dot gnu dot | |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|0000-00-00 00:00:00 |2006-12-13 17:32:28 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (7 preceding siblings ...) 2006-12-13 17:32 ` dnovillo at gcc dot gnu dot org @ 2006-12-13 23:50 ` dnovillo at gcc dot gnu dot org 2006-12-13 23:54 ` dnovillo at gcc dot gnu dot org ` (15 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dnovillo at gcc dot gnu dot org @ 2006-12-13 23:50 UTC (permalink / raw) To: gcc-bugs ------- Comment #9 from dnovillo at gcc dot gnu dot org 2006-12-13 23:50 ------- The memory problem is quite simple: We just have a *lot* of pointers and a *lot* of addressable symbols. Here is a breakdown of what happens on the first call to compute_may_aliases: During the first call to compute_may_aliases: 1- Size of cc1plus is 339Mb 2- Call to compute_points_to_sets grows to 355Mb (+4.72%) 3- Call to compute_flow_insensitive_aliasing grows to 364Mb (+2.54%) 4- Call to compute_flow_sensitive_aliasing grows to 667Mb (+83.2%) The reason for this tremendous growth is quite simple. There are 39,010 SSA name pointers and many of them have their own points-to set, which we store in that name's may-alias set. We grow to 667Mb in the last loop of compute_flow_sensitive_aliasing. One thing we could do is just not use flow-sensitive information in these cases. If we don't set SSA_NAME_PTR_INFO, everything will default to flow-insensitive information and things will Just Work. Perhaps using sparse bitmaps for the may-alias sets might help with memory consumption, but I found these bitmaps to slow down the operand scanner quite a bit in the past. May be worth a try. Danny, thoughts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (8 preceding siblings ...) 2006-12-13 23:50 ` dnovillo at gcc dot gnu dot org @ 2006-12-13 23:54 ` dnovillo at gcc dot gnu dot org 2006-12-14 1:11 ` dberlin at dberlin dot org ` (14 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dnovillo at gcc dot gnu dot org @ 2006-12-13 23:54 UTC (permalink / raw) To: gcc-bugs ------- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 23:54 ------- (In reply to comment #9) > The memory problem is quite simple: We just have a *lot* of pointers and a > *lot* of addressable symbols. Here is a breakdown of what happens on the first > call to compute_may_aliases: > > During the first call to compute_may_aliases: > This is in the function ffparse, BTW. Which has alias sets with 4.2 million elements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (9 preceding siblings ...) 2006-12-13 23:54 ` dnovillo at gcc dot gnu dot org @ 2006-12-14 1:11 ` dberlin at dberlin dot org 2006-12-14 2:50 ` dnovillo at gcc dot gnu dot org ` (13 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dberlin at dberlin dot org @ 2006-12-14 1:11 UTC (permalink / raw) To: gcc-bugs ------- Comment #11 from dberlin at gcc dot gnu dot org 2006-12-14 01:11 ------- Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory On 13 Dec 2006 23:50:17 -0000, dnovillo at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #9 from dnovillo at gcc dot gnu dot org 2006-12-13 23:50 ------- > > The memory problem is quite simple: We just have a *lot* of pointers and a > *lot* of addressable symbols. Here is a breakdown of what happens on the first > call to compute_may_aliases: > > During the first call to compute_may_aliases: > > 1- Size of cc1plus is 339Mb > 2- Call to compute_points_to_sets grows to 355Mb (+4.72%) > 3- Call to compute_flow_insensitive_aliasing grows to 364Mb (+2.54%) > 4- Call to compute_flow_sensitive_aliasing grows to 667Mb (+83.2%) > > The reason for this tremendous growth is quite simple. There are 39,010 SSA > name pointers and many of them have their own points-to set, which we store in > that name's may-alias set. If they had their own set, then compute_points_to_set would have required more memory. >We grow to 667Mb in the last loop of > compute_flow_sensitive_aliasing. > > One thing we could do is just not use flow-sensitive information in these > cases. If we don't set SSA_NAME_PTR_INFO, everything will default to > flow-insensitive information and things will Just Work. > > Perhaps using sparse bitmaps for the may-alias sets might help with memory > consumption, but I found these bitmaps to slow down the operand scanner quite a > bit in the past. May be worth a try. > > Danny, thoughts? If compute_points_to_sets only grows memory by 26 meg, then that's all we need to represent the points-to sets of all these variables So we shoudl be able to do this without using more memory than that. Sadly, we create copies of the result of find_what_p_points_to, then transform it into an array. I'll give the bitmaps a try for the operand scanner and see how it works. I really don't think we should have to turn off information that is only taking 26 meg to store originally :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (10 preceding siblings ...) 2006-12-14 1:11 ` dberlin at dberlin dot org @ 2006-12-14 2:50 ` dnovillo at gcc dot gnu dot org 2006-12-23 14:26 ` hubicka at gcc dot gnu dot org ` (12 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dnovillo at gcc dot gnu dot org @ 2006-12-14 2:50 UTC (permalink / raw) To: gcc-bugs ------- Comment #12 from dnovillo at gcc dot gnu dot org 2006-12-14 02:50 ------- (In reply to comment #11) > I'll give the bitmaps a try for the operand scanner and see how it works. > OK. Hopefully that won't introduce a huge slowdown in the operand scanner. Assigning back to you. -- dnovillo at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|dnovillo at gcc dot gnu dot |dberlin at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (11 preceding siblings ...) 2006-12-14 2:50 ` dnovillo at gcc dot gnu dot org @ 2006-12-23 14:26 ` hubicka at gcc dot gnu dot org 2006-12-23 14:27 ` hubicka at gcc dot gnu dot org ` (11 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: hubicka at gcc dot gnu dot org @ 2006-12-23 14:26 UTC (permalink / raw) To: gcc-bugs ------- Comment #13 from hubicka at gcc dot gnu dot org 2006-12-23 14:26 ------- Note that we've got another noticeable jump in memory consumption today (well at least it would be very important jump if we used just 28MB of memory for aliasing :). Is that also aliasing or shall be analyzed? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (12 preceding siblings ...) 2006-12-23 14:26 ` hubicka at gcc dot gnu dot org @ 2006-12-23 14:27 ` hubicka at gcc dot gnu dot org 2006-12-23 16:21 ` dberlin at dberlin dot org ` (10 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: hubicka at gcc dot gnu dot org @ 2006-12-23 14:27 UTC (permalink / raw) To: gcc-bugs ------- Comment #14 from hubicka at gcc dot gnu dot org 2006-12-23 14:27 ------- Well, actually the testcase now runs out of memory and ICE... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (13 preceding siblings ...) 2006-12-23 14:27 ` hubicka at gcc dot gnu dot org @ 2006-12-23 16:21 ` dberlin at dberlin dot org 2007-01-09 21:17 ` rguenth at gcc dot gnu dot org ` (9 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dberlin at dberlin dot org @ 2006-12-23 16:21 UTC (permalink / raw) To: gcc-bugs ------- Comment #15 from dberlin at gcc dot gnu dot org 2006-12-23 16:21 ------- Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory On 23 Dec 2006 14:26:00 -0000, hubicka at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #13 from hubicka at gcc dot gnu dot org 2006-12-23 14:26 ------- > Note that we've got another noticeable jump in memory consumption today (well > at least it would be very important jump if we used just 28MB of memory for > aliasing :). Is that also aliasing or shall be analyzed? It's possible it was my aliasing fix, but it's hard to say. I had only seen cases where it increased mem usage ~3-5% (this was on large testcases too). It certainly shouldn't run out of memory. In any case, i'm working on testing bitmaps for may-aliases right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (14 preceding siblings ...) 2006-12-23 16:21 ` dberlin at dberlin dot org @ 2007-01-09 21:17 ` rguenth at gcc dot gnu dot org 2007-01-09 21:42 ` Daniel Berlin 2007-01-09 21:42 ` dberlin at dberlin dot org ` (8 subsequent siblings) 24 siblings, 1 reply; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2007-01-09 21:17 UTC (permalink / raw) To: gcc-bugs ------- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-09 21:17 ------- Pling! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2007-01-09 21:17 ` rguenth at gcc dot gnu dot org @ 2007-01-09 21:42 ` Daniel Berlin 0 siblings, 0 replies; 28+ messages in thread From: Daniel Berlin @ 2007-01-09 21:42 UTC (permalink / raw) To: gcc-bugzilla; +Cc: gcc-bugs [-- Attachment #1: Type: text/plain, Size: 307 bytes --] Try the attached, let me know how it goes. On 9 Jan 2007 21:17:05 -0000, rguenth at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-09 21:17 ------- > Pling! > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 > > [-- Attachment #2: operandsbitmaps.diff --] [-- Type: text/x-diff, Size: 26318 bytes --] --- gcc/tree.h (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree.h (/local/gcc-clean) (revision 1114) @@ -2449,10 +2449,14 @@ struct tree_decl_minimal GTY(()) struct tree_memory_tag GTY(()) { struct tree_decl_minimal common; + + bitmap GTY ((skip)) aliases; + unsigned int is_global:1; }; #define MTAG_GLOBAL(NODE) (TREE_MEMORY_TAG_CHECK (NODE)->mtag.is_global) +#define MTAG_ALIASES(NODE) (TREE_MEMORY_TAG_CHECK (NODE)->mtag.aliases) struct tree_struct_field_tag GTY(()) { --- gcc/tree-ssa-alias.c (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree-ssa-alias.c (/local/gcc-clean) (revision 1114) @@ -90,6 +90,7 @@ struct alias_stats_d /* Local variables. */ static struct alias_stats_d alias_stats; +static bitmap_obstack alias_bitmap_obstack; /* Local functions. */ static void compute_flow_insensitive_aliasing (struct alias_info *); @@ -99,7 +100,7 @@ static bool may_alias_p (tree, HOST_WIDE static tree create_memory_tag (tree type, bool is_type_tag); static tree get_smt_for (tree, struct alias_info *); static tree get_nmt_for (tree); -static void add_may_alias (tree, tree, struct pointer_set_t *); +static void add_may_alias (tree, tree); static struct alias_info *init_alias_info (void); static void delete_alias_info (struct alias_info *); static void compute_flow_sensitive_aliasing (struct alias_info *); @@ -194,19 +195,21 @@ static void mark_aliases_call_clobbered (tree tag, VEC (tree, heap) **worklist, VEC (int, heap) **worklist2) { + bitmap aliases; + bitmap_iterator bi; unsigned int i; - VEC (tree, gc) *ma; tree entry; var_ann_t ta = var_ann (tag); if (!MTAG_P (tag)) return; - ma = may_aliases (tag); - if (!ma) + aliases = may_aliases (tag); + if (!aliases) return; - for (i = 0; VEC_iterate (tree, ma, i, entry); i++) + EXECUTE_IF_SET_IN_BITMAP (aliases, 0, i, bi) { + entry = referenced_var (i); if (!unmodifiable_var_p (entry)) { add_to_worklist (entry, worklist, worklist2, ta->escape_mask); @@ -264,7 +267,8 @@ compute_tag_properties (void) changed = false; for (k = 0; VEC_iterate (tree, taglist, k, tag); k++) { - VEC (tree, gc) *ma; + bitmap ma; + bitmap_iterator bi; unsigned int i; tree entry; bool tagcc = is_call_clobbered (tag); @@ -277,8 +281,9 @@ compute_tag_properties (void) if (!ma) continue; - for (i = 0; VEC_iterate (tree, ma, i, entry); i++) + EXECUTE_IF_SET_IN_BITMAP (ma, 0, i, bi) { + entry = referenced_var (i); /* Call clobbered entries cause the tag to be marked call clobbered. */ if (!tagcc && is_call_clobbered (entry)) @@ -508,8 +513,9 @@ sort_mp_info (VEC(mp_info_t,heap) *list) static void create_partition_for (mp_info_t mp_p) { + bitmap_iterator bi; tree mpt, sym; - VEC(tree,gc) *aliases; + bitmap aliases; unsigned i; if (mp_p->num_vops <= (long) MAX_ALIASED_VOPS) @@ -556,11 +562,12 @@ create_partition_for (mp_info_t mp_p) else { aliases = may_aliases (mp_p->var); - gcc_assert (VEC_length (tree, aliases) > 1); + gcc_assert (!bitmap_empty_p (aliases)); mpt = NULL_TREE; - for (i = 0; VEC_iterate (tree, aliases, i, sym); i++) + EXECUTE_IF_SET_IN_BITMAP (aliases, 0, i, bi) { + sym = referenced_var (i); /* Only set the memory partition for aliased symbol SYM if SYM does not belong to another partition. */ if (memory_partition (sym) == NULL_TREE) @@ -614,11 +621,10 @@ rewrite_alias_set_for (tree tag, bitmap else { /* Create a new alias set for TAG with the new partitions. */ - var_ann_t ann; - ann = var_ann (tag); - for (i = 0; VEC_iterate (tree, ann->may_aliases, i, sym); i++) + EXECUTE_IF_SET_IN_BITMAP (MTAG_ALIASES (tag), 0, i, bi) { + sym = referenced_var (i); mpt = memory_partition (sym); if (mpt) bitmap_set_bit (new_aliases, DECL_UID (mpt)); @@ -627,9 +633,7 @@ rewrite_alias_set_for (tree tag, bitmap } /* Rebuild the may-alias array for TAG. */ - VEC_free (tree, gc, ann->may_aliases); - EXECUTE_IF_SET_IN_BITMAP (new_aliases, 0, i, bi) - VEC_safe_push (tree, gc, ann->may_aliases, referenced_var (i)); + bitmap_copy (MTAG_ALIASES (tag), new_aliases); } } @@ -691,7 +695,10 @@ compute_memory_partitions (void) /* Each reference to VAR will produce as many VOPs as elements exist in its alias set. */ mp.var = var; - mp.num_vops = VEC_length (tree, may_aliases (var)); + if (!may_aliases (var)) + mp.num_vops = 0; + else + mp.num_vops = bitmap_count_bits (may_aliases (var)); /* No point grouping singleton alias sets. */ if (mp.num_vops <= 1) @@ -1112,7 +1119,9 @@ init_alias_info (void) if (gimple_aliases_computed_p (cfun)) { unsigned i; - + + bitmap_obstack_release (&alias_bitmap_obstack); + /* Similarly, clear the set of addressable variables. In this case, we can just clear the set because addressability is only computed here. */ @@ -1124,7 +1133,10 @@ init_alias_info (void) var_ann_t ann = var_ann (var); ann->is_aliased = 0; - ann->may_aliases = NULL; + + /* Move bitmaps to obstack. */ + if (MTAG_P (var)) + MTAG_ALIASES (var) = NULL; /* Since we are about to re-discover call-clobbered variables, clear the call-clobbered flag. Variables that @@ -1180,6 +1192,7 @@ init_alias_info (void) /* Next time, we will need to reset alias information. */ cfun->gimple_df->aliases_computed_p = true; + bitmap_obstack_initialize (&alias_bitmap_obstack); return ai; } @@ -1331,6 +1344,20 @@ create_name_tags (void) VEC_free (tree, heap, with_ptvars); } +/* Union the alias set SET into the may-aliases for TAG */ +static void +union_alias_set_into (tree tag, bitmap set) +{ + bitmap ma = MTAG_ALIASES (tag); + + if (bitmap_empty_p (set)) + return; + + if (!ma) + ma = MTAG_ALIASES (tag) = BITMAP_ALLOC (&alias_bitmap_obstack); + bitmap_ior_into (ma, set); +} + /* For every pointer P_i in AI->PROCESSED_PTRS, create may-alias sets for the name memory tag (NMT) associated with P_i. If P_i escapes, then its @@ -1358,46 +1385,51 @@ compute_flow_sensitive_aliasing (struct for (i = 0; VEC_iterate (tree, ai->processed_ptrs, i, ptr); i++) { - unsigned j; struct ptr_info_def *pi = SSA_NAME_PTR_INFO (ptr); tree tag = symbol_mem_tag (SSA_NAME_VAR (ptr)); - bitmap_iterator bi; /* Set up aliasing information for PTR's name memory tag (if it has one). Note that only pointers that have been dereferenced will have a name memory tag. */ if (pi->name_mem_tag && pi->pt_vars) - EXECUTE_IF_SET_IN_BITMAP (pi->pt_vars, 0, j, bi) - { - add_may_alias (pi->name_mem_tag, referenced_var (j), NULL); - if (j != DECL_UID (tag)) - add_may_alias (tag, referenced_var (j), NULL); - } + { + if (!bitmap_empty_p (pi->pt_vars)) + { + union_alias_set_into (pi->name_mem_tag, pi->pt_vars); + union_alias_set_into (tag, pi->pt_vars); + bitmap_clear_bit (MTAG_ALIASES (tag), DECL_UID (tag)); + + /* It may be the case that this the tag uid was the only + bit we had set in the aliases list, and in this case, + we don't want to keep an empty bitmap, as this + asserts in tree-ssa-operands.c . */ + if (bitmap_empty_p (MTAG_ALIASES (tag))) + BITMAP_FREE (MTAG_ALIASES (tag)); + } + } } } -/* Return TRUE if at least one symbol in TAG's alias set is also - present in SET1. */ +/* Return TRUE if at least one symbol in TAG2's alias set is also + present in TAG1's alias set. */ static bool -have_common_aliases_p (struct pointer_set_t *set1, tree tag2) +have_common_aliases_p (bitmap tag1aliases, bitmap tag2aliases) { - unsigned i; - VEC(tree,gc) *aliases2; - if (set1 == NULL) + /* This is the old behavior of have_common_aliases_p, which is to + return false if both sets are empty, or one set is and the other + isn't. */ + if ((tag1aliases == NULL && tag2aliases != NULL) + || (tag2aliases == NULL && tag1aliases != NULL) + || (tag1aliases == NULL && tag2aliases == NULL)) return false; - aliases2 = may_aliases (tag2); - for (i = 0; i < VEC_length (tree, aliases2); i++) - if (pointer_set_contains (set1, VEC_index (tree, aliases2, i))) - return true; - return false; + return bitmap_intersect_p (tag1aliases, tag2aliases); } - /* Compute type-based alias sets. Traverse all the pointers and addressable variables found in setup_pointers_and_addressables. @@ -1412,20 +1444,11 @@ compute_flow_insensitive_aliasing (struc { size_t i; - /* Initialize pointer sets to keep track of duplicates in alias - sets. */ - for (i = 0; i < ai->num_pointers; i++) - { - tree tag = symbol_mem_tag (ai->pointers[i]->var); - var_ann (tag)->common.aux = NULL; - } - /* For every pointer P, determine which addressable variables may alias with P's symbol memory tag. */ for (i = 0; i < ai->num_pointers; i++) { size_t j; - struct pointer_set_t *already_added; struct alias_map_d *p_map = ai->pointers[i]; tree tag = symbol_mem_tag (p_map->var); tree var; @@ -1434,13 +1457,6 @@ compute_flow_insensitive_aliasing (struc if (PTR_IS_REF_ALL (p_map->var)) continue; - /* Retrieve or create the set of symbols that have already been - added to TAG's alias set. */ - if (var_ann (tag)->common.aux == NULL) - var_ann (tag)->common.aux = (void *) pointer_set_create (); - - already_added = (struct pointer_set_t *) var_ann (tag)->common.aux; - for (j = 0; j < ai->num_addressable_vars; j++) { struct alias_map_d *v_map; @@ -1470,7 +1486,7 @@ compute_flow_insensitive_aliasing (struc || get_subvars_for_var (var) == NULL); /* Add VAR to TAG's may-aliases set. */ - add_may_alias (tag, var, already_added); + add_may_alias (tag, var); } } } @@ -1498,20 +1514,18 @@ compute_flow_insensitive_aliasing (struc for (i = 0; i < ai->num_pointers; i++) { size_t j; - struct pointer_set_t *set1; struct alias_map_d *p_map1 = ai->pointers[i]; tree tag1 = symbol_mem_tag (p_map1->var); + bitmap may_aliases1 = MTAG_ALIASES (tag1); if (PTR_IS_REF_ALL (p_map1->var)) continue; - set1 = (struct pointer_set_t *) var_ann (tag1)->common.aux; - for (j = i + 1; j < ai->num_pointers; j++) { struct alias_map_d *p_map2 = ai->pointers[j]; tree tag2 = symbol_mem_tag (p_map2->var); - VEC(tree,gc) *may_aliases2 = may_aliases (tag2); + bitmap may_aliases2 = may_aliases (tag2); if (PTR_IS_REF_ALL (p_map2->var)) continue; @@ -1522,37 +1536,21 @@ compute_flow_insensitive_aliasing (struc /* The two pointers may alias each other. If they already have symbols in common, do nothing. */ - if (have_common_aliases_p (set1, tag2)) + if (have_common_aliases_p (may_aliases1, may_aliases2)) continue; - if (set1 == NULL) - { - set1 = pointer_set_create (); - var_ann (tag1)->common.aux = (void *) set1; - } - - if (VEC_length (tree, may_aliases2) > 0) + if (may_aliases2 && !bitmap_empty_p (may_aliases2)) { - unsigned k; - tree sym; - - /* Add all the aliases for TAG2 into TAG1's alias set. */ - for (k = 0; VEC_iterate (tree, may_aliases2, k, sym); k++) - add_may_alias (tag1, sym, set1); + union_alias_set_into (tag1, may_aliases2); } else { /* Since TAG2 does not have any aliases of its own, add TAG2 itself to the alias set of TAG1. */ - add_may_alias (tag1, tag2, set1); + add_may_alias (tag1, tag2); } } - if (set1) - { - pointer_set_destroy (set1); - var_ann (tag1)->common.aux = NULL; - } } } @@ -1570,14 +1568,13 @@ static void finalize_ref_all_pointers (struct alias_info *ai) { size_t i; - struct pointer_set_t *already_added = pointer_set_create (); /* First add the real call-clobbered variables. */ for (i = 0; i < ai->num_addressable_vars; i++) { tree var = ai->addressable_vars[i]->var; if (is_call_clobbered (var)) - add_may_alias (ai->ref_all_symbol_mem_tag, var, already_added); + add_may_alias (ai->ref_all_symbol_mem_tag, var); } /* Then add the call-clobbered pointer memory tags. See @@ -1589,10 +1586,9 @@ finalize_ref_all_pointers (struct alias_ continue; tag = symbol_mem_tag (ptr); if (is_call_clobbered (tag)) - add_may_alias (ai->ref_all_symbol_mem_tag, tag, already_added); + add_may_alias (ai->ref_all_symbol_mem_tag, tag); } - pointer_set_destroy (already_added); } @@ -1960,14 +1956,11 @@ may_alias_p (tree ptr, HOST_WIDE_INT mem } -/* Add ALIAS to the set of variables that may alias VAR. If - ALREADY_ADDED is given, it is used to avoid adding the same alias - more than once to VAR's alias set. */ +/* Add ALIAS to the set of variables that may alias VAR. */ static void -add_may_alias (tree var, tree alias, struct pointer_set_t *already_added) +add_may_alias (tree var, tree alias) { - var_ann_t v_ann = get_var_ann (var); var_ann_t a_ann = get_var_ann (alias); /* Don't allow self-referential aliases. */ @@ -1984,14 +1977,10 @@ add_may_alias (tree var, tree alias, str gcc_assert (TREE_CODE (var) == SYMBOL_MEMORY_TAG || TREE_CODE (var) == NAME_MEMORY_TAG); - if (v_ann->may_aliases == NULL) - v_ann->may_aliases = VEC_alloc (tree, gc, 2); - - /* Avoid adding duplicates. */ - if (already_added && pointer_set_insert (already_added, alias)) - return; - - VEC_safe_push (tree, gc, v_ann->may_aliases, alias); + if (MTAG_ALIASES (var) == NULL) + MTAG_ALIASES (var) = BITMAP_ALLOC (&alias_bitmap_obstack); + + bitmap_set_bit (MTAG_ALIASES (var), DECL_UID (alias)); a_ann->is_aliased = 1; } @@ -2506,19 +2495,19 @@ debug_points_to_info (void) void dump_may_aliases_for (FILE *file, tree var) { - VEC(tree, gc) *aliases; + bitmap aliases; - if (TREE_CODE (var) == SSA_NAME) - var = SSA_NAME_VAR (var); - - aliases = var_ann (var)->may_aliases; + aliases = MTAG_ALIASES (var); if (aliases) { - size_t i; + bitmap_iterator bi; + unsigned int i; tree al; + fprintf (file, "{ "); - for (i = 0; VEC_iterate (tree, aliases, i, al); i++) + EXECUTE_IF_SET_IN_BITMAP (aliases, 0, i, bi) { + al = referenced_var (i); print_generic_expr (file, al, dump_flags); fprintf (file, " "); } @@ -2579,31 +2568,26 @@ may_be_aliased (tree var) bool is_aliased_with (tree tag, tree sym) { - size_t i; - VEC(tree,gc) *aliases; - tree al; + bitmap aliases; if (var_ann (sym)->is_aliased) { - aliases = var_ann (tag)->may_aliases; + aliases = MTAG_ALIASES (tag); if (aliases == NULL) return false; - for (i = 0; VEC_iterate (tree, aliases, i, al); i++) - if (al == sym) - return true; + return bitmap_bit_p (aliases, DECL_UID (sym)); } else { - aliases = var_ann (sym)->may_aliases; + gcc_assert (MTAG_P (sym)); + aliases = MTAG_ALIASES (sym); if (aliases == NULL) return false; - for (i = 0; VEC_iterate (tree, aliases, i, al); i++) - if (al == tag) - return true; + return bitmap_bit_p (aliases, DECL_UID (tag)); } return false; @@ -2619,37 +2603,26 @@ is_aliased_with (tree tag, tree sym) static tree add_may_alias_for_new_tag (tree tag, tree var) { - VEC(tree,gc) *aliases; - struct pointer_set_t *already_added; - unsigned i; - tree al; + bitmap aliases; aliases = may_aliases (var); /* Case 1: |aliases| == 1 */ - if (VEC_length (tree, aliases) == 1) + if (bitmap_count_bits (aliases) == 1) { - tree ali = VEC_index (tree, aliases, 0); + tree ali = referenced_var (bitmap_first_set_bit (aliases)); if (TREE_CODE (ali) == SYMBOL_MEMORY_TAG) return ali; } - already_added = pointer_set_create (); - for (i = 0; VEC_iterate (tree, may_aliases (tag), i, al); i++) - pointer_set_insert (already_added, al); - /* Case 2: |aliases| == 0 */ if (aliases == NULL) - add_may_alias (tag, var, already_added); + add_may_alias (tag, var); else { /* Case 3: |aliases| > 1 */ - for (i = 0; VEC_iterate (tree, aliases, i, al); i++) - add_may_alias (tag, al, already_added); + union_alias_set_into (tag, aliases); } - - pointer_set_destroy (already_added); - return tag; } @@ -2736,7 +2709,7 @@ new_type_alias (tree ptr, tree var, tree /* Can happen only if 'Case 1' of add_may_alias_for_new_tag took place. Since more than one svar was found, we add 'ali' as one of the may_aliases of the new tag. */ - add_may_alias (tag, ali, NULL); + add_may_alias (tag, ali); ali = tag; } } --- gcc/tree-flow-inline.h (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree-flow-inline.h (/local/gcc-clean) (revision 1114) @@ -303,13 +303,12 @@ bb_for_stmt (tree t) return ann ? ann->bb : NULL; } -/* Return the may_aliases varray for variable VAR, or NULL if it has +/* Return the may_aliases bitmap for variable VAR, or NULL if it has no may aliases. */ -static inline VEC(tree, gc) * +static inline bitmap may_aliases (tree var) { - var_ann_t ann = var_ann (var); - return ann ? ann->may_aliases : NULL; + return MTAG_ALIASES (var); } /* Return the line number for EXPR, or return -1 if we have no line --- gcc/tree-dfa.c (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree-dfa.c (/local/gcc-clean) (revision 1114) @@ -383,7 +383,7 @@ dump_variable (FILE *file, tree var) print_generic_expr (file, gimple_default_def (cfun, var), dump_flags); } - if (may_aliases (var)) + if (MTAG_P (var) && may_aliases (var)) { fprintf (file, ", may aliases: "); dump_may_aliases_for (file, var); --- gcc/tree-ssa.c (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree-ssa.c (/local/gcc-clean) (revision 1114) @@ -380,17 +380,20 @@ verify_flow_insensitive_alias_info (void FOR_EACH_REFERENCED_VAR (var, rvi) { - size_t j; - var_ann_t ann; - VEC(tree,gc) *may_aliases; + unsigned int j; + bitmap aliases; tree alias; + bitmap_iterator bi; - ann = var_ann (var); - may_aliases = ann->may_aliases; + if (!MTAG_P (var) || !MTAG_ALIASES (var)) + continue; + + aliases = MTAG_ALIASES (var); - for (j = 0; VEC_iterate (tree, may_aliases, j, alias); j++) + EXECUTE_IF_SET_IN_BITMAP (aliases, 0, j, bi) { - bitmap_set_bit (visited, DECL_UID (alias)); + alias = referenced_var (j); + bitmap_set_bit (visited, j); if (TREE_CODE (alias) != MEMORY_PARTITION_TAG && !may_be_aliased (alias)) --- gcc/tree-flow.h (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree-flow.h (/local/gcc-clean) (revision 1114) @@ -266,11 +266,6 @@ struct var_ann_d GTY(()) to convert to hash table? */ tree symbol_mem_tag; - /* Variables that may alias this variable. This may only be set on - memory tags (NAME_MEMORY_TAG or TYPE_MEMORY_TAG). FIXME, move to - struct tree_memory_tag. */ - VEC(tree, gc) *may_aliases; - /* Used when going out of SSA form to indicate which partition this variable represents storage for. */ unsigned partition; @@ -431,7 +426,7 @@ extern void set_bb_for_stmt (tree, basic static inline bool noreturn_call_p (tree); static inline void update_stmt (tree); static inline bool stmt_modified_p (tree); -static inline VEC(tree, gc) *may_aliases (tree); +static inline bitmap may_aliases (tree); static inline int get_lineno (tree); static inline const char *get_filename (tree); static inline bool is_exec_stmt (tree); --- gcc/tree-ssa-structalias.c (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree-ssa-structalias.c (/local/gcc-clean) (revision 1114) @@ -235,10 +235,18 @@ struct variable_info /* True if the variable is directly the target of a dereference. This is used to track which variables are *actually* dereferenced - so we can prune their points to listed. This is equivalent to the - indirect_target flag when no merging of variables happens. */ + so we can prune their points to sets using TBAA. */ unsigned int directly_dereferenced:1; + /* True if the variable is either dereferenced, or was merged with a + variable that is dereferenced. This is only used for used SMT + purposes. Points that are completely undereferenced never need + SMT sets. The reason SSA_NAME_PTR_INFO is not okay enough for + this purpose is because it considered escaping variables to be + dereferenced, but for purposes of SMT usage, this is not + necessary. */ + unsigned int dereferenced:1; + /* True if this is a variable created by the constraint analysis, such as heap variables and constraints we had to break up. */ unsigned int is_artificial_var:1; @@ -377,6 +385,7 @@ new_var_info (tree t, unsigned int id, c ret->address_taken = false; ret->indirect_target = false; ret->directly_dereferenced = false; + ret->dereferenced = false; ret->is_artificial_var = false; ret->is_heap_var = false; ret->is_special_var = false; @@ -729,16 +738,20 @@ condense_varmap_nodes (unsigned int to, for (i = 0; VEC_iterate (constraint_t, srcvi->complex, i, c); i++) { /* In complex constraints for node src, we may have either - a = *src, and *src = a. */ + a = *src, and *src = a, or an offseted constraint which are + always added to the rhs node's constraints. */ if (c->rhs.type == DEREF) c->rhs.var = to; - else + else if (c->lhs.type == DEREF) c->lhs.var = to; + else + c->rhs.var = to; } constraint_set_union (&tovi->complex, &srcvi->complex); VEC_free (constraint_t, heap, srcvi->complex); srcvi->complex = NULL; + tovi->dereferenced |= srcvi->dereferenced; } @@ -1874,9 +1887,15 @@ process_constraint (constraint_t t) gcc_assert (lhs.type != INCLUDES); if (lhs.type == DEREF) - get_varinfo (lhs.var)->directly_dereferenced = true; + { + get_varinfo (lhs.var)->directly_dereferenced = true; + get_varinfo (lhs.var)->dereferenced = true; + } if (rhs.type == DEREF) - get_varinfo (rhs.var)->directly_dereferenced = true; + { + get_varinfo (rhs.var)->directly_dereferenced = true; + get_varinfo (rhs.var)->dereferenced = true; + } if (!use_field_sensitive) { @@ -3894,7 +3913,8 @@ set_used_smts (void) if (vi->is_special_var || vi->node != vi->id || !SSA_VAR_P (var) || (pi && !pi->is_dereferenced) || (TREE_CODE (var) == VAR_DECL && !may_be_aliased (var)) - || !POINTER_TYPE_P (TREE_TYPE (var))) + || !POINTER_TYPE_P (TREE_TYPE (var)) + || !vi->dereferenced) continue; if (TREE_CODE (var) == SSA_NAME) @@ -3920,7 +3940,7 @@ merge_smts_into (tree p, varinfo_t vi) unsigned int i; bitmap_iterator bi; tree smt; - VEC(tree, gc) *aliases; + bitmap aliases; tree var = p; if (TREE_CODE (p) == SSA_NAME) @@ -3944,15 +3964,9 @@ merge_smts_into (tree p, varinfo_t vi) bitmap_set_bit (vi->finished_solution, i); } - aliases = var_ann (smt)->may_aliases; + aliases = MTAG_ALIASES (smt); if (aliases) - { - size_t k; - tree al; - for (k = 0; VEC_iterate (tree, aliases, k, al); k++) - bitmap_set_bit (vi->finished_solution, - DECL_UID (al)); - } + bitmap_ior_into (vi->finished_solution, aliases); } } --- gcc/tree-ssa-reassoc.c (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree-ssa-reassoc.c (/local/gcc-clean) (revision 1114) @@ -1496,6 +1496,7 @@ fini_reassoc (void) static unsigned int execute_reassoc (void) { + return 0; init_reassoc (); do_reassoc (); --- gcc/tree-ssa-operands.c (/mirror/gcc-trunk) (revision 1114) +++ gcc/tree-ssa-operands.c (/local/gcc-clean) (revision 1114) @@ -1439,7 +1439,7 @@ add_virtual_operand (tree var, stmt_ann_ tree full_ref, HOST_WIDE_INT offset, HOST_WIDE_INT size, bool for_clobber) { - VEC(tree,gc) *aliases; + bitmap aliases = NULL; tree sym; var_ann_t v_ann; @@ -1477,7 +1477,8 @@ add_virtual_operand (tree var, stmt_ann_ if (flags & opf_no_vops) return; - aliases = v_ann->may_aliases; + if (MTAG_P (var)) + aliases = MTAG_ALIASES (var); if (aliases == NULL) { /* The variable is not aliased or it is an alias tag. */ @@ -1488,19 +1489,20 @@ add_virtual_operand (tree var, stmt_ann_ } else { - unsigned i; + bitmap_iterator bi; + unsigned int i; tree al; /* The variable is aliased. Add its aliases to the virtual operands. */ - gcc_assert (VEC_length (tree, aliases) != 0); + gcc_assert (!bitmap_empty_p (aliases)); if (flags & opf_def) { bool none_added = true; - - for (i = 0; VEC_iterate (tree, aliases, i, al); i++) + EXECUTE_IF_SET_IN_BITMAP (aliases, 0, i, bi) { + al = referenced_var (i); if (!access_can_touch_variable (full_ref, al, offset, size)) continue; @@ -1530,14 +1532,15 @@ add_virtual_operand (tree var, stmt_ann_ else { bool none_added = true; - for (i = 0; VEC_iterate (tree, aliases, i, al); i++) + EXECUTE_IF_SET_IN_BITMAP (aliases, 0, i, bi) { + al = referenced_var (i); if (!access_can_touch_variable (full_ref, al, offset, size)) continue; none_added = false; append_vuse (al); } - + /* Similarly, append a virtual uses for VAR itself, when it is an alias tag. */ if (v_ann->is_aliased || none_added) Property changes on: ___________________________________________________________________ Name: svk:merge +138bc75d-0d04-0410-961f-82ee72b054a4:/trunk:120584 +23c3ee16-a423-49b3-8738-b114dc1aabb6:/local/gcc-pta-dev:259 +23c3ee16-a423-49b3-8738-b114dc1aabb6:/local/gcc-trunk:531 +7dca8dba-45c1-47dc-8958-1a7301c5ed47:/local-gcc/md-constraint:113709 +f367781f-d768-471e-ba66-e306e17dff77:/local/gen-rework-20060122:110130 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (15 preceding siblings ...) 2007-01-09 21:17 ` rguenth at gcc dot gnu dot org @ 2007-01-09 21:42 ` dberlin at dberlin dot org 2007-01-10 18:39 ` rguenth at gcc dot gnu dot org ` (7 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dberlin at dberlin dot org @ 2007-01-09 21:42 UTC (permalink / raw) To: gcc-bugs ------- Comment #17 from dberlin at gcc dot gnu dot org 2007-01-09 21:42 ------- Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory Try the attached, let me know how it goes. On 9 Jan 2007 21:17:05 -0000, rguenth at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-09 21:17 ------- > Pling! > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 > > ------- Comment #18 from dberlin at gcc dot gnu dot org 2007-01-09 21:42 ------- Created an attachment (id=12874) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12874&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (16 preceding siblings ...) 2007-01-09 21:42 ` dberlin at dberlin dot org @ 2007-01-10 18:39 ` rguenth at gcc dot gnu dot org 2007-01-11 18:12 ` rguenth at gcc dot gnu dot org ` (6 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2007-01-10 18:39 UTC (permalink / raw) To: gcc-bugs ------- Comment #19 from rguenth at gcc dot gnu dot org 2007-01-10 18:39 ------- We'll see with tonights run of the tester. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (17 preceding siblings ...) 2007-01-10 18:39 ` rguenth at gcc dot gnu dot org @ 2007-01-11 18:12 ` rguenth at gcc dot gnu dot org 2007-01-13 23:02 ` rguenth at gcc dot gnu dot org ` (5 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2007-01-11 18:12 UTC (permalink / raw) To: gcc-bugs ------- Comment #20 from rguenth at gcc dot gnu dot org 2007-01-11 18:12 ------- Again tonight - Mark broke bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (18 preceding siblings ...) 2007-01-11 18:12 ` rguenth at gcc dot gnu dot org @ 2007-01-13 23:02 ` rguenth at gcc dot gnu dot org 2007-01-14 1:22 ` Daniel Berlin 2007-01-14 1:22 ` dberlin at dberlin dot org ` (4 subsequent siblings) 24 siblings, 1 reply; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2007-01-13 23:02 UTC (permalink / raw) To: gcc-bugs ------- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-13 23:02 ------- The patch fixed the freefem memory regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2007-01-13 23:02 ` rguenth at gcc dot gnu dot org @ 2007-01-14 1:22 ` Daniel Berlin 0 siblings, 0 replies; 28+ messages in thread From: Daniel Berlin @ 2007-01-14 1:22 UTC (permalink / raw) To: gcc-bugzilla; +Cc: gcc-bugs okay, i'll update changelog, submit and commit. On 13 Jan 2007 23:02:13 -0000, rguenth at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-13 23:02 ------- > The patch fixed the freefem memory regression. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (19 preceding siblings ...) 2007-01-13 23:02 ` rguenth at gcc dot gnu dot org @ 2007-01-14 1:22 ` dberlin at dberlin dot org 2007-01-14 15:06 ` rguenth at gcc dot gnu dot org ` (3 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: dberlin at dberlin dot org @ 2007-01-14 1:22 UTC (permalink / raw) To: gcc-bugs ------- Comment #22 from dberlin at gcc dot gnu dot org 2007-01-14 01:22 ------- Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory okay, i'll update changelog, submit and commit. On 13 Jan 2007 23:02:13 -0000, rguenth at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #21 from rguenth at gcc dot gnu dot org 2007-01-13 23:02 ------- > The patch fixed the freefem memory regression. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (20 preceding siblings ...) 2007-01-14 1:22 ` dberlin at dberlin dot org @ 2007-01-14 15:06 ` rguenth at gcc dot gnu dot org 2007-03-30 15:59 ` dberlin at gcc dot gnu dot org ` (2 subsequent siblings) 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2007-01-14 15:06 UTC (permalink / raw) To: gcc-bugs ------- Comment #23 from rguenth at gcc dot gnu dot org 2007-01-14 15:06 ------- Can it be the patch changes result of alias analysis? I get (big) runtime differences (but maybe due to unrelated changes) with the tester from Jan 13 (patched) vs. Jan 14 (unpatched). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (21 preceding siblings ...) 2007-01-14 15:06 ` rguenth at gcc dot gnu dot org @ 2007-03-30 15:59 ` dberlin at gcc dot gnu dot org 2007-03-31 13:42 ` rguenth at gcc dot gnu dot org 2007-03-31 13:43 ` [Bug tree-optimization/30089] [4.3 Regression] " rguenth at gcc dot gnu dot org 24 siblings, 0 replies; 28+ messages in thread From: dberlin at gcc dot gnu dot org @ 2007-03-30 15:59 UTC (permalink / raw) To: gcc-bugs ------- Comment #24 from dberlin at gcc dot gnu dot org 2007-03-30 16:58 ------- This is fixed now, rihgt? I forgot to add the PR number to the changelog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (22 preceding siblings ...) 2007-03-30 15:59 ` dberlin at gcc dot gnu dot org @ 2007-03-31 13:42 ` rguenth at gcc dot gnu dot org 2007-03-31 13:43 ` [Bug tree-optimization/30089] [4.3 Regression] " rguenth at gcc dot gnu dot org 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2007-03-31 13:42 UTC (permalink / raw) To: gcc-bugs ------- Comment #25 from rguenth at gcc dot gnu dot org 2007-03-31 14:42 ------- Yes. -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug tree-optimization/30089] [4.3 Regression] Compiling FreeFem3d uses unreasonable amount of time and memory 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org ` (23 preceding siblings ...) 2007-03-31 13:42 ` rguenth at gcc dot gnu dot org @ 2007-03-31 13:43 ` rguenth at gcc dot gnu dot org 24 siblings, 0 replies; 28+ messages in thread From: rguenth at gcc dot gnu dot org @ 2007-03-31 13:43 UTC (permalink / raw) To: gcc-bugs -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Compiling FreeFem3d uses |[4.3 Regression] Compiling |unreasonable amount of time |FreeFem3d uses unreasonable |and memory |amount of time and memory Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2007-03-31 13:43 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-12-06 17:15 [Bug tree-optimization/30089] New: Compiling FreeFem3d uses unreasonable amount of time and memory rguenth at gcc dot gnu dot org 2006-12-06 17:17 ` [Bug tree-optimization/30089] " rguenth at gcc dot gnu dot org 2006-12-06 17:19 ` rguenth at gcc dot gnu dot org 2006-12-06 17:20 ` rguenth at gcc dot gnu dot org 2006-12-07 4:48 ` dberlin at gcc dot gnu dot org 2006-12-07 12:41 ` rguenth at gcc dot gnu dot org 2006-12-07 14:07 ` rguenth at gcc dot gnu dot org 2006-12-12 16:44 ` rguenth at gcc dot gnu dot org 2006-12-13 17:32 ` dnovillo at gcc dot gnu dot org 2006-12-13 23:50 ` dnovillo at gcc dot gnu dot org 2006-12-13 23:54 ` dnovillo at gcc dot gnu dot org 2006-12-14 1:11 ` dberlin at dberlin dot org 2006-12-14 2:50 ` dnovillo at gcc dot gnu dot org 2006-12-23 14:26 ` hubicka at gcc dot gnu dot org 2006-12-23 14:27 ` hubicka at gcc dot gnu dot org 2006-12-23 16:21 ` dberlin at dberlin dot org 2007-01-09 21:17 ` rguenth at gcc dot gnu dot org 2007-01-09 21:42 ` Daniel Berlin 2007-01-09 21:42 ` dberlin at dberlin dot org 2007-01-10 18:39 ` rguenth at gcc dot gnu dot org 2007-01-11 18:12 ` rguenth at gcc dot gnu dot org 2007-01-13 23:02 ` rguenth at gcc dot gnu dot org 2007-01-14 1:22 ` Daniel Berlin 2007-01-14 1:22 ` dberlin at dberlin dot org 2007-01-14 15:06 ` rguenth at gcc dot gnu dot org 2007-03-30 15:59 ` dberlin at gcc dot gnu dot org 2007-03-31 13:42 ` rguenth at gcc dot gnu dot org 2007-03-31 13:43 ` [Bug tree-optimization/30089] [4.3 Regression] " rguenth at gcc dot gnu dot org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).