[Bug tree-optimization/20643] [4.0/4.1 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[Bug tree-optimization/20643] [4.0/4.1 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[sje at cup dot hp dot com]

------- Comment #4 from sje at cup dot hp dot com  2005-10-03 15:10 -------
Just to clarify the main issue here, my main concern here is not the conversion
of the for loop to a do loop but rather the alias disambiguation and the
movement of loop invariant code out of the inner most loop in P7Viterbi. 
Because the new alias analysis is not as good as it used to be (with respect to
structures) more code is left in the inner loop.  This is why the test case is
so much slower now than before.


-- 


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

[Bug tree-optimization/20643] [4.0/4.1 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[mmitchel at gcc dot gnu dot org]

------- Comment #5 from mmitchel at gcc dot gnu dot org  2005-10-31 02:51 -------
Dan, is there any chance of fixing this for 4.1?


-- 

mmitchel 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=20643

[Bug tree-optimization/20643] [4.0/4.1 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[dberlin at gcc dot gnu dot org]

------- Comment #6 from dberlin at gcc dot gnu dot org  2005-10-31 03:43 -------
Realistically?
No.
I'm about to start solving it on the improved-aliasing branch.


-- 


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

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[mmitchel at gcc dot gnu dot org]

------- Comment #7 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=20643

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[bonzini at gnu dot org]

------- Comment #8 from bonzini at gnu dot org  2006-04-18 14:15 -------
Mark, I don't believe there is any chance that it be fixed in 4.0/4.1?


-- 


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

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2006-04-28 14:06 -------
This is really because we do not decompose structs pointed to by parameters for
their elements, so a write to an int clobbers all of plan7_s.

With -O2 timings on i686 are for me (averages of three runs)

3.4.6    5.4s
4.0.3    7.4s
4.1.0    6.1s
4.2.0    6.6s

manually PREing gives 5.2s for mainline.


-- 

rguenth 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=20643

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[mmitchel at gcc dot gnu dot org]

------- Comment #10 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=20643

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[anemo at mba dot ocn dot ne dot jp]

------- Comment #11 from anemo at mba dot ocn dot ne dot jp  2006-07-16 13:21 -------
I have a similer optimization problem with this tiny function.

void foo(int *a)
{
        int i;
        for (i = 0; i < 100; i++)
                a[0] += a[1];
}

All gcc 4.x I tried generate load and store in inner loop.
On http://gcc.gnu.org/ml/gcc/2006-07/msg00282.html, I posted some results.
Is this a same probelm?  If not, I should file another bug report.  Thank you.


-- 


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

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[steven at gcc dot gnu dot org]

------- Comment #12 from steven at gcc dot gnu dot org  2006-07-16 13:52 -------
The test case in comment #11 looks like a classic store motion opportunity to
me.  GCC 3.3 performs the store motion, GCC 4.2 r115467 does not.

Zdenek, I thought tree-ssa-lim should be able to do store motion in loops?


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu dot
                   |                            |org
   Last reconfirmed|2006-02-01 04:41:41         |2006-07-16 13:52:59
               date|                            |


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

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[rakdver at gcc dot gnu dot org]

------- Comment #13 from rakdver at gcc dot gnu dot org  2006-07-17 11:54 -------
(In reply to comment #12)
> The test case in comment #11 looks like a classic store motion opportunity to
> me.  GCC 3.3 performs the store motion, GCC 4.2 r115467 does not.
> 
> Zdenek, I thought tree-ssa-lim should be able to do store motion in loops?

Yes, however again, the alias analysis does not tell it that a[0] does not
alias a[1]; once that is fixed, tree-ssa-lim should work just fine.


-- 


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

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[dberlin at dberlin dot org]

------- Comment #14 from dberlin at gcc dot gnu dot org  2006-07-17 13:34 -------
Subject: Re:  [4.0/4.1/4.2 Regression] Tree loop
 optimizer does worse job than RTL loop optimizer

rakdver at gcc dot gnu dot org wrote:
> ------- Comment #13 from rakdver at gcc dot gnu dot org  2006-07-17 11:54 -------
> (In reply to comment #12)
>> The test case in comment #11 looks like a classic store motion opportunity to
>> me.  GCC 3.3 performs the store motion, GCC 4.2 r115467 does not.
>>
>> Zdenek, I thought tree-ssa-lim should be able to do store motion in loops?
> 
> Yes, however again, the alias analysis does not tell it that a[0] does not
> alias a[1]; once that is fixed, tree-ssa-lim should work just fine.

This is because it's an incoming parameter, and as a result, this
doesn't look at all like an array access, but just a random pointer access.

I have no plans to make the alias analysis algorithm reconstruct array
indexes from random pointer arithmetic.

--Dan


-- 


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

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[anemo at mba dot ocn dot ne dot jp]

------- Comment #15 from anemo at mba dot ocn dot ne dot jp  2006-07-18 16:53 -------
(In reply to comment #14)
> This is because it's an incoming parameter, and as a result, this
> doesn't look at all like an array access, but just a random pointer access.
> 
> I have no plans to make the alias analysis algorithm reconstruct array
> indexes from random pointer arithmetic.

I do not think reconstructing array indexes are needed,
but is it hard to tell that *(a+0) never be an alias of *(a+1) ?


-- 


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

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[dberlin at dberlin dot org]

------- Comment #16 from dberlin at gcc dot gnu dot org  2006-07-18 17:03 -------
Subject: Re:  [4.0/4.1/4.2 Regression] Tree loop
 optimizer does worse job than RTL loop optimizer

anemo at mba dot ocn dot ne dot jp wrote:
> ------- Comment #15 from anemo at mba dot ocn dot ne dot jp  2006-07-18 16:53 -------
> (In reply to comment #14)
>> This is because it's an incoming parameter, and as a result, this
>> doesn't look at all like an array access, but just a random pointer access.
>>
>> I have no plans to make the alias analysis algorithm reconstruct array
>> indexes from random pointer arithmetic.
> 
> I do not think reconstructing array indexes are needed,
> but is it hard to tell that *(a+0) never be an alias of *(a+1) ?

We already do say this when we know the offsets.  The point is that
without reconstructing the array indexes, we'd have to follow use-def
chains for *every single pointer access* on *every single operand
update*, in order to attempt to get the offsets and disambiguate them.

This is incredibly slow.


-- 


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

[Bug tree-optimization/20643] [4.0/4.1/4.2/4.3 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[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=20643

[Bug tree-optimization/20643] [4.0/4.1/4.2/4.3 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2007-06-11 00:53 -------
the pointer_plus branch improves the code here (I can't tell if it fixes the
problem fully).


-- 


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

[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[pinskia at gcc dot gnu dot org]

------- Comment #18 from pinskia at gcc dot gnu dot org  2007-07-04 17:58 -------
Yep this was fixed by Pointer_plus.
The load of hmm->tsc is no longer in the inner most loop.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression]
                   |Tree loop optimizer does    |Tree loop optimizer does
                   |worse job than RTL loop     |worse job than RTL loop
                   |optimizer                   |optimizer


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

[Bug tree-optimization/20643] [4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[jsm28 at gcc dot gnu dot org]

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


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2 Regression] Tree   |[4.2 Regression] Tree loop
                   |loop optimizer does worse   |optimizer does worse job
                   |job than RTL loop optimizer |than RTL loop optimizer
   Target Milestone|4.1.3                       |4.2.5


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

[Bug tree-optimization/20643] [4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer

[jsm28 at gcc dot gnu dot org]

------- Comment #20 from jsm28 at gcc dot gnu dot org  2009-03-30 15:43 -------
Closing 4.2 branch, fixed in 4.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to fail|4.0.4                       |4.0.4 4.2.5
      Known to work|                            |4.3.0
         Resolution|                            |FIXED
   Target Milestone|4.2.5                       |4.3.0


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