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
* [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
* 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
` (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).