[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- 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.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- 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 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.65.4s 4.0.37.4s 4.1.06.1s 4.2.06.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
--- 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
--- 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
