This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: IRA performance regressions on PPC
On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
> On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado <luisgpm@linux.vnet.ibm.com> wrote:
> >
> > On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
> >> On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> >> >
> >> > H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
> >>
> >> I won't apply any non-IRA related patches to ira-merge branch so
> >> that you can get a fair comparison for IRA without regressions
> >> introduced by other changes.
> >>
> >> > 1-3 days usually because gcc community and RA reviewers are very responsive.
> >> > So I don't see a big difference in using ira-merge and trunk. I'd only
> >> > recommend to apply patch
> >> >
> >> > http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00427.html
> >> >
> >> > first because it is critical for performance but I don't know when it will
> >> > be approved.
> >> >
> >>
> >> I checked this patch into ira-merge branch.
> >
> > I've verifired applu and facerec against the ira-merge branch. The
> > numbers are just as bad as trunk. So, apparently, the last patch didn't
> > improve performance on those benchmarks.
> >
> > Any other ideas you'd like me to try on IRA?
> >
> >
>
> Can you verify if your problem is related to
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
Even with data that shows us that the degradation occured between
revisions 139589 and 139590 (139589 showing good numbers and 139590
showing bad numbers), would it still make sense to consider ticket 28690
as the possible reason for this degradation?
Thanks,
Luis