This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] patch: Re: reg+reg addressing mode on SPARC
- To: jakub at redhat dot com
- Subject: Re: [RFC] patch: Re: reg+reg addressing mode on SPARC
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Mon, 13 Aug 2001 09:02:51 -0700 (PDT)
- Cc: dann at ics dot uci dot edu (Dan Nicolaescu), jbuck at synopsys dot com (Joe Buck), gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
>
> On Fri, Aug 10, 2001 at 06:46:44PM -0700, Dan Nicolaescu wrote:
> > Meanwhile let's see if my patch is correct...
> > (it bootstraps on sparc-sun-solaris2.8)
>
> > + if (code0 == REG || code1 == REG)
> > + return 2;
Jakub writes:
> It apparently does not do what was described it does: it gives higher cost
> for %reg+anything.
> And the example you gave is IMHO really not related to addressing mode
> costs, after all they are the same. The thing is we need to find out why
> loop optimization does not do its job properly.
Unfortunately, this loop optimization problem has been repeatedly reported
for the last three years and no one has done anything, so I'm not holding
my breath. (I think that this bug may be a primary reason that Sun's
compilers have substantially better numbers than gcc, as it affects almost
any Fortran-style loop, where array indexing rather than a pointer is used
to sweep an array). I suspect that in the particular example Dan tried
his patch on, the tweak has the effect of working around the bug: a
loop invariant that is not recognized changes to one that is recognized.
But there's an old bit of wisdom from Usenet: the most reliable way to
motivate some expert to post a correct answer is not to just ask a
question, but to post a wrong answer.
So what if we threaten to put this into the compiler unless someone fixes
it correctly? :-)