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