[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #17 from steven at gcc dot gnu dot org  2005-10-16 23:20 -------
On AMD64, I now get the following timings:

                           -O1     -O2
3.3 (profilebootstrapped)  46.64   46.90
4.1 (checking=release)     72.82   156.43

In 4.1, the Big Spenders are "dominance frontiers" (41% usr)
and "tree operand scan" (also 41%) for -O1.  For -O2 those two
also are big time black holes, and the 3 gcse.c CPROP passes
join them at the top of the profile ("dominance frontiers" 18%,
"tree operand scan" 18%, "CPROP 1" 17%, "CPROP 2" 9%, "bypass
jumps" 10%).

So this is still a regression from GCC 3.3.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.0.0                       |4.0.0 4.1.0
   Last reconfirmed|2005-10-16 22:35:50         |2005-10-16 23:20:30
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[bonzini at gcc dot gnu dot org]

------- Comment #18 from bonzini at gcc dot gnu dot org  2005-10-18 08:36 -------
Steven, how does your df.c-based cprop fare on this testcase?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[amacleod at redhat dot com]

------- Comment #19 from amacleod at redhat dot com  2005-10-18 12:25 -------
Created an attachment (id=10017)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10017&action=view)
patch for operand scan

Now that correct_use_link is *only* used for real uses, it is no longer
profitable to try to "shortcut" the search for the owner of a use list. The
shortcut use to look at each previous node as the list was traversed, and check
to see if the stmt was modified. If it wasn't, we knew that node was in the
correct list and wouldnt have to scan all the way back to the owner.

well, this testcase was spending almost all its time checking for
stmt_modified_p....  something like 250,000,000 checks on 50,000 calls.

I've removed the no longer useful shortcut, and the results are as follows:

bootstrapped and no new regressions on i686-pc-linux-gnu.

Andrew


                    x86-64:
-O1 on testcase:
before patch     tree operand scan     :   8.00 (36%)
                 TOTAL                 :  22.18

after patch:     tree operand scan     :   1.41 ( 9%)
                 TOTAL                 :  15.62

-O2 on testcase:
before patch     tree operand scan     :   7.88 (15%)
                 TOTAL                 :  53.08

after patch:     tree operand scan     :   1.42 ( 3%)
                 TOTAL                 :  46.94


                    x86:
-O1 on testcase:
before patch     tree operand scan     :   2.54 (17%)
                 TOTAL                 :  14.60


after patch:     tree operand scan     :   1.01 ( 8%)
                 TOTAL                 :  12.51

-O2 on testcase:
before patch     tree operand scan     :   2.95 ( 8%)
                 TOTAL                 :  39.20

after patch:     tree operand scan     :   1.06 ( 3%)
                 TOTAL                 :  38.03


pretty much a wash on cc1-i and cpgram.cc testcases on both targets.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #20 from steven at gcc dot gnu dot org  2005-10-29 22:38 -------
amacleod, are you going to post your patch and/or commit it??


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[mmitchel at gcc dot gnu dot org]

------- Comment #21 from mmitchel at gcc dot gnu dot org  2005-10-31 02:02 -------
I'm going to leave this as P2, since we've got a proposed patch in Comment #19.
 Andrew, do you need a review on that patch?  Or, is there any other reason it
hasn't been committed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[amacleod at redhat dot com]

------- Comment #22 from amacleod at redhat dot com  2005-10-31 13:33 -------
It will be checked in shortly. I got your OK for this stage last week, and I
was merely waiting for the SVN switchover freeze to expire, trying a new build
and getting back to work today.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[amacleod at redhat dot com]

------- Comment #23 from amacleod at redhat dot com  2005-10-31 14:41 -------
Hmm. This has been committed, but the commit hasn't shown up yet. Perhaps
because I tagged it as a tree-optimization PR and I now notice that its marked
as rtl-optimization?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[dberlin at gcc dot gnu dot org]

------- Comment #24 from dberlin at gcc dot gnu dot org  2005-10-31 15:04 -------
I fixed the bug that was preventing it from sending it to this bug, it should
pop up in a second


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[amacleod at gcc dot gnu dot org]

------- Comment #25 from amacleod at redhat dot com  2005-10-31 15:19 -------
Subject: Bug 19097

Author: amacleod
Date: Mon Oct 31 13:38:05 2005
New Revision: 106272

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106272
Log:

2005-10-31  Andrew MacLeod  <amacleod@redhat.com>

        PR tree-optimization/19097
        * tree-ssa-operands.c (correct_use_link): Don't look for modified
stmts.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-operands.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #26 from steven at gcc dot gnu dot org  2005-10-31 17:12 -------
Moving back to new, because I don't know if the GCSE CPROP issue with implicit
sets is also already fixed.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2005-10-16 23:20:30         |2005-10-31 17:12:20
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #27 from steven at gcc dot gnu dot org  2005-11-08 00:18 -------
On AMD64, revision 106596M (the M is for a local loop-invariant.c
patch, nothing special), compiler built with --enable-checking=release:

at -O1:
 tree operand scan     :   1.50 (10%) usr   0.09 (17%) sys   1.62 (10%) wall    
 dominance frontiers   :   9.09 (60%) usr   0.00 ( 0%) sys   9.20 (58%) wall    
 TOTAL                 :  15.05             0.53            15.80

at -O2:
 tree VRP              :  12.20 (23%) usr   0.03 ( 3%) sys  12.44 (23%) wall
 dominance frontiers   :   9.17 (18%) usr   0.01 ( 1%) sys   9.30 (17%) wall    
 CPROP 1               :   8.17 (16%) usr   0.16 (16%) sys   8.44 (16%) wall
 CPROP 2               :   5.54 (11%) usr   0.11 (11%) sys   5.72 (11%) wall
 bypass jumps          :   5.57 (11%) usr   0.11 (11%) sys   5.75 (11%) wall
 TOTAL                 :  52.31             1.00            53.98

For GCC 3.3.5 at -O1 the total time is 26s, and at -O2 it is 31s.



For AMD64 -m32 -march=i686:

at -O1:
 tree operand scan     :   1.48 (10%) usr   0.09 (18%) sys   1.59 (10%) wall
 dominance frontiers   :   9.03 (61%) usr   0.00 ( 0%) sys   9.14 (59%) wall
 TOTAL                 :  14.70             0.49            15.39

at -O2:
 tree VRP              :  11.84 (24%) usr   0.04 ( 4%) sys  12.02 (24%) wall
 dominance frontiers   :   9.11 (19%) usr   0.02 ( 2%) sys   9.25 (18%) wall
 CPROP 1               :   7.54 (15%) usr   0.10 (11%) sys   7.74 (15%) wall
 CPROP 2               :   4.99 (10%) usr   0.10 (11%) sys   5.15 (10%) wall
 bypass jumps          :   4.96 (10%) usr   0.10 (11%) sys   5.12 (10%) wall
 TOTAL                 :  48.97             0.93            50.54

For GCC 3.3.5 at -O1 the total time is 25s, and at -O2 it is 28s.

Compared to my measurements from comment #17, this is good progress.  James, do
you think we can close this bug now?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[phython at gcc dot gnu dot org]

------- Comment #28 from phython at gcc dot gnu dot org  2005-11-08 06:48 -------
Steven: How long does 4.0 take to compile this function on your box?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1/4.2 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #29 from steven at gcc dot gnu dot org  2006-01-08 16:02 -------
User times:

optimization    |       GCC version
level           |       3.3-hammer      4.0             4.1
----------------+------------------------------------------------
-O0             |       0m7.248s        0m1.684s        0m1.800s
-O1             |       0m24.786s       0m18.489s       0m18.749s
-O2             |       0m30.390s       0m54.147s       1m9.636s

The top 5 time consumers for each compiler:
timevar         |  GCC version
at -O2          |  3.3-hammer           4.0                 4.1
----------------+--------------------------------------------------
1.              |  cfg cleanup (45%)    dom. front. (24%)   tree VRP (27%)
2.              |  branch pred. (21%)   CPROP 1 (17%)       dom. front. (14%)
3.              |  rest of comp. (10%)  CPROP 2 (13%)       CPROP 1 (14%)
4.              |  CSE 2 (8%)           bypass jumps (13%)  CPROP 2 (10%)
5.              |  global CSE (3%)      CSE (9%)            bypass jumps (9%)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1/4.2 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #30 from steven at gcc dot gnu dot org  2006-01-08 16:08 -------
Other than VRP taking so much time for GCC 4.1, there are no surprises in the
timings I just added in comment #29 for GCC 4.0 and GCC 4.1.

Computing dominance frontiers is just not a linear operation (especially not
for a function with this many of them :-).  "CPROP 1", "CPROP 2", and "bypass
jumps" are all the same algorithm (const/copy propagation in gcse.c) which also
has known non-linear algorithms for strange test cases like the one for this
bug report.

If only VRP wouldn't suck up so much time here, I would call this one FIXED...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1/4.2 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #31 from steven at gcc dot gnu dot org  2006-01-08 16:14 -------
Re. the timings in comment #29, I should have said that my GCC 3.3 was
bootstrapped, but the GCC 4.0 and GCC 4.1 I used were built with "-O0 -g".  I
added 3.3 numbers for "ballpark" reference, not for actual comparison.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1/4.2 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #32 from steven at gcc dot gnu dot org  2006-01-08 18:16 -------
I have bootstrapped 4.0 and 4.1 and re-timed:
GCC 4.0 0m38.118s
GCC 4.1 0m51.059s

The distribution of the compile time is not significantly different from the
timings of the -O0 compilers.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1/4.2 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #33 from steven at gcc dot gnu dot org  2006-01-08 18:32 -------
So where are we wrt. GCC 3.3-hammer at -O2?

compiler     absolute time       relative to 3.3-hammer
GCC 3.3      0m30.390s           1.00
GCC 4.0      0m38.118s           1.25
GCC 4.1      0m51.059s           1.68

Jump bypassing is new in GCC 3.4, that accounts for a 5.47s slowdown.  Without
jump bypassing, GCC 4.0 would be ~7% slower than GCC 3.3.

The time for "tree VRP" in GCC 4.1 is 12.12s.  Together with jump bypassing,
this is a ~18s slowdown for GCC 4.1 wrt. GCC 3.3 just due to new passes. 
Without VRP and jump bypassing, GCC 4.1 would be 11% slower than GCC 3.3.

>From the GCC 4.1 .vrp tree dump: "Number of ASSERT_EXPR expressions inserted:
10000".  This is exactly the number of "else" clauses in the test case.  This
requires a huge effort on update_ssa (which is slow already anyway) to fix up
SSA form for all these pseudo-copies (ASSERT_EXPRs are really just copies). 
The resulting SSA replacement table is therefore also just _huge_ (also from
the .vrp dump):

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

b_2 -> { b_1 }
b_3 -> { b_1 }
b_4 -> { b_1 }
b_5 -> { b_1 }
b_6 -> { b_1 }
b_7 -> { b_1 }
b_8 -> { b_1 }
b_9 -> { b_1 }
(etc.)

This is unique behavior that can only be triggered for unreasonable code like
this test case.  Eventually it doesn't help to insert all those ASSERT_EXPRs,
so it would still be nice, perhaps, to fix ASSERT_EXPR insertion to better
understand that it is acting stupidly.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [3.4/4.0/4.1/4.2 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[steven at gcc dot gnu dot org]

------- Comment #34 from steven at gcc dot gnu dot org  2006-01-08 18:40 -------
Another factor contributing to the huge compile time requirements of VRP for
this test case is the number of equivalences recorded:

Value ranges after VRP ("..." meaning I cut away a *cough* few b_i SSA names
;-):

b_1: VARYING
b_2: ~[19998, 19998]  EQUIVALENCES: { b_1 b_3 ... b_10001 } (10000 elements)
b_3: ~[19997, 19997]  EQUIVALENCES: { b_1 b_4 ... b_10001 } (9999 elements)
b_4: ~[19996, 19996]  EQUIVALENCES: { b_1 b_5 ... b_10001 } (9998 elements)
...
b_9999: ~[10001, 10001]  EQUIVALENCES: { b_1 b_10000 b_10001 } (3 elements)
b_10000: ~[10000, 10000]  EQUIVALENCES: { b_1 b_10001 } (2 elements)
b_10001: ~[1, 1]  EQUIVALENCES: { b_1 } (1 elements)

I think that, if this is something we should worry about at all, this belongs
in a separate bug report about VRP.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

------- Comment #35 from steven at gcc dot gnu dot org  2006-01-09 22:26 -------
...and so we go blame Diego for the 4.1/4.2 problem, because gcse.c CPROP is no
longer a problem here for GCC 4.0/4.1/4.2.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.0.0 4.1.0                 |4.1.0 4.2.0
      Known to work|3.3.4                       |3.3.4 4.0.0
            Summary|[3.4/4.0/4.1/4.2 regression]|[4.1/4.2 regression]
                   |Quadratic behavior with many|Quadratic behavior with many
                   |sets for the same register  |sets for the same register
                   |in gcse CPROP               |in VRP


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

------- Comment #36 from steven at gcc dot gnu dot org  2006-02-05 21:37 -------
I think the easiest way to fix this is to limit the length of the EQUIVALENCE
chains somehow.  I've collected some numbers about the number of elements in
the EQUIVALENCE chains of GCC 2.7.2 (which is the version of GCC in SPEC2000):


frequency   # of elements
  20342          0
  43484          1
  13230          2
   1701          3
    456          4
    207          5
     81          6
     44          7
     24          8
     18          9
      4          10
      4          11
      4          12
      4          13
      2          14
      2          15
      2          16

So if we cut off the element lists at, say, 20 elements, we shouldn't be
missing a significant number of optimizations.

I haven't looked at how such a cut-off should be implemented.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

------- Comment #37 from steven at gcc dot gnu dot org  2006-02-05 22:47 -------
At least I get VRP time down to nothing with a patchlet like this one:

Index: tree-vrp.c
===================================================================
--- tree-vrp.c  (revision 110617)
+++ tree-vrp.c  (working copy)
@@ -326,7 +326,7 @@ add_equivalence (bitmap equiv, tree var)
   value_range_t *vr = vr_value[ver];

   bitmap_set_bit (equiv, ver);
-  if (vr && vr->equiv)
+  if (vr && vr->equiv && bitmap_count_bits (vr->equiv) < 20)
     bitmap_ior_into (equiv, vr->equiv);
 }


For a proper patch, the number should of course be a PARAM and I think using
bitmap_count_bits penalizes the common case too much (walking the whole bitmap
is cache expensive even for small bitmaps).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP

[mmitchel at gcc dot gnu dot org]

------- Comment #38 from mmitchel at gcc dot gnu dot org  2006-02-24 00:25 -------
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.0                       |4.1.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP

[mmitchel at gcc dot gnu dot org]

------- Comment #39 from mmitchel at gcc dot gnu dot org  2006-05-25 02:32 -------
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.1                       |4.1.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug rtl-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP

[amylaar at gcc dot gnu dot org]

------- Comment #40 from amylaar at gcc dot gnu dot org  2006-08-24 20:50 -------
(In reply to comment #37)
> For a proper patch, the number should of course be a PARAM and I think using
> bitmap_count_bits penalizes the common case too much (walking the whole bitmap
> is cache expensive even for small bitmaps).

How about:

 -  if (vr && vr->equiv)
 +  if (vr && vr->equiv && vr->equiv->first
        && (!vr->equiv->first->next
            || bitmap_count_bits (vr->equiv) < VRP_EQUIVALENCE_THRESHOLD)))
      bitmap_ior_into (equiv, vr->equiv);

The 0 bit case is sped up, and the 1 bit case is guaranteed to only need two
pointer dereferences to check that there are not too many bits.
Other small bit numbers should still have a high likelyhood to he handled
without a bitmap_count_bits call.
The quick & dirty check might allow more than VRP_EQUIVALENCE_THRESHOLD
bits through if they are tightly packed, but that is still imited to 64
for a host with 32 bit longs, 128 for a host with 64 bit longs.


-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amylaar at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP

[rguenth at gcc dot gnu dot org]

------- Comment #41 from rguenth at gcc dot gnu dot org  2006-10-10 11:19 -------
We're still 100% slower than 4.0.3 on the mainline:

Execution times (seconds)
 callgraph construction:   0.21 ( 0%) usr   0.03 ( 2%) sys   0.23 ( 0%) wall  
11563 kB (13%) ggc
 callgraph optimization:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
 937 kB ( 1%) ggc
 ipa reference         :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 ipa type escape       :   0.03 ( 0%) usr   0.02 ( 1%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 cfg cleanup           :   0.57 ( 1%) usr   0.02 ( 1%) sys   0.62 ( 1%) wall   
1250 kB ( 1%) ggc
 trivially dead code   :   0.10 ( 0%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall   
   0 kB ( 0%) ggc
 life analysis         :   0.33 ( 0%) usr   0.01 ( 1%) sys   0.35 ( 0%) wall   
1250 kB ( 1%) ggc
 life info update      :   0.13 ( 0%) usr   0.00 ( 0%) sys   0.14 ( 0%) wall   
   0 kB ( 0%) ggc
 alias analysis        :   0.21 ( 0%) usr   0.00 ( 0%) sys   0.16 ( 0%) wall   
   1 kB ( 0%) ggc
 register scan         :   0.09 ( 0%) usr   0.00 ( 0%) sys   0.10 ( 0%) wall   
   0 kB ( 0%) ggc
 rebuild jump labels   :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 preprocessing         :   0.11 ( 0%) usr   0.03 ( 2%) sys   0.14 ( 0%) wall   
 704 kB ( 1%) ggc
 lexical analysis      :   0.07 ( 0%) usr   0.21 (12%) sys   0.20 ( 0%) wall   
   0 kB ( 0%) ggc
 parser                :   0.09 ( 0%) usr   0.06 ( 3%) sys   0.23 ( 0%) wall   
5224 kB ( 6%) ggc
 integration           :   0.08 ( 0%) usr   0.01 ( 1%) sys   0.08 ( 0%) wall   
   0 kB ( 0%) ggc
 tree gimplify         :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
 625 kB ( 1%) ggc
 tree eh               :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree CFG construction :   0.12 ( 0%) usr   0.03 ( 2%) sys   0.15 ( 0%) wall  
14606 kB (16%) ggc
 tree CFG cleanup      :   0.67 ( 1%) usr   0.01 ( 1%) sys   0.65 ( 1%) wall   
   0 kB ( 0%) ggc
 tree VRP              :  40.92 (46%) usr   0.24 (13%) sys  41.26 (46%) wall  
10356 kB (11%) ggc
 tree copy propagation :   0.09 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall   
   0 kB ( 0%) ggc
 tree store copy prop  :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree find ref. vars   :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree PTA              :   0.09 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
   6 kB ( 0%) ggc
 tree alias analysis   :   0.14 ( 0%) usr   0.10 ( 6%) sys   0.21 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA rewrite      :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA other        :   0.02 ( 0%) usr   0.01 ( 1%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA incremental  :   0.07 ( 0%) usr   0.01 ( 1%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree operand scan     :   0.29 ( 0%) usr   0.17 ( 9%) sys   0.35 ( 0%) wall   
2306 kB ( 3%) ggc
 dominator optimization:   0.47 ( 1%) usr   0.01 ( 1%) sys   0.52 ( 1%) wall   
7031 kB ( 8%) ggc
 tree STORE-CCP        :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree CCP              :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree PHI const/copy prop:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
     0 kB ( 0%) ggc
 tree reassociation    :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
   0 kB ( 0%) ggc
 tree PRE              :   0.09 ( 0%) usr   0.01 ( 1%) sys   0.10 ( 0%) wall   
   0 kB ( 0%) ggc
 tree FRE              :   0.05 ( 0%) usr   0.01 ( 1%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 tree code sinking     :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree linearize phis   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 tree forward propagate:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree conservative DCE :   0.09 ( 0%) usr   0.00 ( 0%) sys   0.10 ( 0%) wall   
   0 kB ( 0%) ggc
 tree aggressive DCE   :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 tree DSE              :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
   0 kB ( 0%) ggc
 PHI merge             :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree loop init        :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 tree copy headers     :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA uncprop      :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA to normal    :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree rename SSA copies:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 dominance frontiers   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 dominance computation :   0.48 ( 1%) usr   0.03 ( 2%) sys   0.47 ( 1%) wall   
   0 kB ( 0%) ggc
 control dependences   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 expand                :   0.81 ( 1%) usr   0.06 ( 3%) sys   0.99 ( 1%) wall  
19285 kB (21%) ggc
 jump                  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 CSE                   :   2.18 ( 2%) usr   0.01 ( 1%) sys   2.18 ( 2%) wall   
   0 kB ( 0%) ggc
 loop analysis         :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall   
   0 kB ( 0%) ggc
 global CSE            :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 CPROP 1               :  14.66 (17%) usr   0.26 (14%) sys  14.93 (17%) wall   
2031 kB ( 2%) ggc
 PRE                   :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 CPROP 2               :  10.01 (11%) usr   0.19 (10%) sys  10.21 (11%) wall   
1406 kB ( 2%) ggc
 bypass jumps          :   9.88 (11%) usr   0.21 (12%) sys  10.10 (11%) wall   
1406 kB ( 2%) ggc
 CSE 2                 :   2.08 ( 2%) usr   0.01 ( 1%) sys   2.09 ( 2%) wall   
   0 kB ( 0%) ggc
 branch prediction     :   0.16 ( 0%) usr   0.00 ( 0%) sys   0.15 ( 0%) wall   
 625 kB ( 1%) ggc
 flow analysis         :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 combiner              :   0.11 ( 0%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall   
 312 kB ( 0%) ggc
 if-conversion         :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 regmove               :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall   
   0 kB ( 0%) ggc
 local alloc           :   0.13 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%) wall   
   1 kB ( 0%) ggc
 global alloc          :   0.33 ( 0%) usr   0.00 ( 0%) sys   0.33 ( 0%) wall   
   0 kB ( 0%) ggc
 reload CSE regs       :   0.13 ( 0%) usr   0.01 ( 1%) sys   0.14 ( 0%) wall   
2502 kB ( 3%) ggc
 flow 2                :   0.03 ( 0%) usr   0.01 ( 1%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 if-conversion 2       :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 peephole 2            :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall   
2187 kB ( 2%) ggc
 rename registers      :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 scheduling 2          :   0.27 ( 0%) usr   0.01 ( 1%) sys   0.28 ( 0%) wall   
 314 kB ( 0%) ggc
 machine dep reorg     :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
1250 kB ( 1%) ggc
 reorder blocks        :   0.15 ( 0%) usr   0.02 ( 1%) sys   0.17 ( 0%) wall   
1875 kB ( 2%) ggc
 final                 :   0.13 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%) wall   
 512 kB ( 1%) ggc
 TOTAL                 :  88.19             1.81            90.10             
91385 kB


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[rguenth at gcc dot gnu dot org]

------- Comment #42 from rguenth at gcc dot gnu dot org  2007-09-17 13:11 -------
Still slow.

 cfg cleanup           :   7.10 (10%) usr   0.16 (10%) sys   7.26 (10%) wall   
 625 kB ( 1%) ggc
 tree VRP              :  27.40 (39%) usr   0.39 (23%) sys  27.91 (38%) wall   
7602 kB (11%) ggc
 CPROP 1               :  12.32 (17%) usr   0.26 (15%) sys  12.58 (17%) wall   
1562 kB ( 2%) ggc
 CPROP 2               :   8.79 (12%) usr   0.20 (12%) sys   9.03 (12%) wall   
1406 kB ( 2%) ggc
 bypass jumps          :   8.73 (12%) usr   0.20 (12%) sys   8.96 (12%) wall   
1406 kB ( 2%) ggc
 TOTAL                 :  70.94             1.68            73.05             
71071 kB


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-10-31 17:12:20         |2007-09-17 13:11:02
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

------- Comment #43 from steven at gcc dot gnu dot org  2007-11-09 22:08 -------
IMVHO this should be closed as WONTFIX.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[sebpop at gmail dot com]

------- Comment #44 from sebpop at gmail dot com  2007-11-11 05:16 -------
Subject: Re:  [4.1/4.2/4.3 regression] Quadratic behavior with many sets for
the same register in VRP

> IMVHO this should be closed as WONTFIX.

Steven, why isn't your patch from comment #37 not a candidate for
fixing this bug?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[stevenb dot gcc at gmail dot com]

------- Comment #45 from stevenb dot gcc at gmail dot com  2007-11-11 09:23 -------
Subject: Re:  [4.1/4.2/4.3 regression] Quadratic behavior with many sets for
the same register in VRP

Because it costs more than it brings: compile time on average goes
_up_ with that patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[rguenth at gcc dot gnu dot org]

------- Comment #46 from rguenth at gcc dot gnu dot org  2007-11-11 12:16 -------
Note that on the mainline equiv processing can be completely turned off by
just tweaking add_equivalence () to do nothing.

There are a few missed optimizations if you do that, but I belive the important
kind of things there should be done in a separate pass (or DOM, which at least
in the past could do these).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

------- Comment #47 from steven at gcc dot gnu dot org  2007-12-18 13:46 -------
(From update of attachment 10017)
Patch is obsolete because it was commited.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10017|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

------- Comment #48 from steven at gcc dot gnu dot org  2008-01-23 08:52 -------
The priority of this bug is too high.  If it wasn't just for recording that
this behavior exists in VRP and CPROP, I would propose to just close this bug
as WONTFIX.  The test case is just too obscure, no man or machine would
normally generate anything like this.

So can a release manager please lower the priority of this bug report?

For GCC 4.4 I hopefully will nuke the CPROP problem.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

[rguenth at gcc dot gnu dot org]

------- Comment #49 from rguenth at gcc dot gnu dot org  2008-01-23 09:06 -------
I think it is reasonable to build in limits into passes that do work not
linear (or at least quadratic) in the number of statements, BBs or edges.

The testcase is probably just extracting the core problem from a real-world
testcase (where the situation is probably also not that bad).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.2/4.3/4.4 regression] Quadratic behavior with many sets for the same register in VRP

[jsm28 at gcc dot gnu dot org]

------- Comment #50 from jsm28 at gcc dot gnu dot org  2008-07-04 16:47 -------
Closing 4.1 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2/4.3/4.4 regression]|[4.2/4.3/4.4 regression]
                   |Quadratic behavior with many|Quadratic behavior with many
                   |sets for the same register  |sets for the same register
                   |in VRP                      |in VRP
   Target Milestone|4.1.3                       |4.2.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.3/4.4/4.5 regression] Quadratic behavior with many sets for the same register in VRP

[jsm28 at gcc dot gnu dot org]

------- Comment #51 from jsm28 at gcc dot gnu dot org  2009-03-31 16:42 -------
Closing 4.2 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2/4.3/4.4/4.5 regression]|[4.3/4.4/4.5 regression]
                   |Quadratic behavior with many|Quadratic behavior with many
                   |sets for the same register  |sets for the same register
                   |in VRP                      |in VRP
   Target Milestone|4.2.5                       |4.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.3/4.4/4.5 regression] Quadratic behavior with many sets for the same register in VRP

[rguenth at gcc dot gnu dot org]

------- Comment #52 from rguenth at gcc dot gnu dot org  2009-08-04 12:26 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug tree-optimization/19097] [4.3/4.4/4.5 regression] Quadratic behavior with many sets for the same register in VRP

[steven at gcc dot gnu dot org]

------- Comment #53 from steven at gcc dot gnu dot org  2009-12-24 13:02 -------
I cannot reproduce this anymore on ia64 -- at least not for VRP and CPROP. The
slowest pass is now expand:

 dominator optimization:   0.40 ( 1%) usr   0.00 ( 0%) sys   0.40 ( 1%) wall   
2188 kB ( 3%) ggc
 tree CCP              :   0.17 ( 0%) usr   0.00 ( 0%) sys   0.16 ( 0%) wall   
   0 kB ( 0%) ggc
 tree PHI const/copy prop:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
     0 kB ( 0%) ggc
 tree split crit edges :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree reassociation    :   0.11 ( 0%) usr   0.00 ( 0%) sys   0.10 ( 0%) wall   
   0 kB ( 0%) ggc
 tree PRE              :   0.16 ( 0%) usr   0.00 ( 0%) sys   0.16 ( 0%) wall   
   1 kB ( 0%) ggc
 tree FRE              :   0.12 ( 0%) usr   0.00 ( 1%) sys   0.12 ( 0%) wall   
   1 kB ( 0%) ggc
 tree code sinking     :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 tree linearize phis   :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall   
   0 kB ( 0%) ggc
 tree forward propagate:   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 tree conservative DCE :   0.08 ( 0%) usr   0.01 ( 2%) sys   0.10 ( 0%) wall   
   0 kB ( 0%) ggc
 tree aggressive DCE   :   0.28 ( 0%) usr   0.00 ( 1%) sys   0.28 ( 0%) wall   
   3 kB ( 0%) ggc
 tree buildin call DCE :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree DSE              :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 PHI merge             :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 complete unrolling    :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree loop init        :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree copy headers     :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SSA uncprop      :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 tree rename SSA copies:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 tree switch initialization conversion:   0.01 ( 0%) usr   0.00 ( 0%) sys  
0.01 ( 0%) wall       0 kB ( 0%) ggc
 dominance frontiers   :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 dominance computation :   0.62 ( 1%) usr   0.00 ( 1%) sys   0.64 ( 1%) wall   
   0 kB ( 0%) ggc
 control dependences   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall   
   0 kB ( 0%) ggc
 expand                :   3.13 ( 5%) usr   0.06 ( 7%) sys   3.21 ( 5%) wall  
17093 kB (26%) ggc
 forward prop          :   0.79 ( 1%) usr   0.00 ( 1%) sys   0.79 ( 1%) wall   
 703 kB ( 1%) ggc
 CSE                   :   1.36 ( 2%) usr   0.00 ( 0%) sys   1.36 ( 2%) wall   
   0 kB ( 0%) ggc
 dead code elimination :   0.15 ( 0%) usr   0.00 ( 0%) sys   0.16 ( 0%) wall   
   0 kB ( 0%) ggc
 dead store elim1      :   0.39 ( 1%) usr   0.00 ( 0%) sys   0.39 ( 1%) wall   
 390 kB ( 1%) ggc
 loop analysis         :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall   
   0 kB ( 0%) ggc
 CPROP                 :   1.96 ( 3%) usr   0.18 (23%) sys   2.15 ( 3%) wall   
6094 kB ( 9%) ggc
 PRE                   :   1.26 ( 2%) usr   0.20 (27%) sys   1.46 ( 2%) wall   
   0 kB ( 0%) ggc
 auto inc dec          :   0.19 ( 0%) usr   0.00 ( 0%) sys   0.19 ( 0%) wall   
   0 kB ( 0%) ggc
 CSE 2                 :   1.69 ( 3%) usr   0.00 ( 0%) sys   1.69 ( 3%) wall   
1288 kB ( 2%) ggc
 branch prediction     :   0.22 ( 0%) usr   0.00 ( 0%) sys   0.22 ( 0%) wall   
   0 kB ( 0%) ggc
 combiner              :   0.62 ( 1%) usr   0.00 ( 0%) sys   0.62 ( 1%) wall   
 234 kB ( 0%) ggc
 if-conversion         :   0.05 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall   
   0 kB ( 0%) ggc
 scheduling            :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 integrated RA         :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
 512 kB ( 1%) ggc
 reload                :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 scheduling 2          :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   8 kB ( 0%) ggc
 tree if-combine       :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall   
   0 kB ( 0%) ggc
 TOTAL                 :  61.41             0.77            62.18             
66790 kB

But this expand slowness also manifests itself at -O0 (IRA and gimplifier
slow), and at -O1 and -O3 (expand). I don't find this unreasnable at all, for
20000 conditionals and 20000 function calls (and all the stack and temp slots
saving/restoring involved). Closing.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097