This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: missed optimization, would be very helpful
- To: Zack Weinberg <zack at rabi dot columbia dot edu>
- Subject: Re: missed optimization, would be very helpful
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Sun, 17 Jan 1999 00:12:13 -0700
- cc: egcs at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <199901011852.NAA07301@rabi.phys.columbia.edu>you write:
> On Thu, 31 Dec 1998 23:03:25 -0400, Horst von Brand wrote:
> >Zack Weinberg <zack@rabi.columbia.edu> said:
> >> In a loop of the form
> >>
> >> while (condition) (*int_ptr)++;
> >>
> >> gcc generates a read-mod-write cycle to the memory location *int_ptr at
> each
> >> iteration of the loop.
>
> >
> >It's still there with egcs-19981226. On i586:
> >
>
> This is what I see too. rth doesn't get that on Alpha, so it's an i386.md
> problem at this point. A guess at a kludge: if the incdi pattern were
> changed to not allow memory operands, that might force the optimization.
> But that's overkill.
I think this is another example of how we want to do post-reload instruction
splitting for the x86.
If we can find a scratch register after reload, then we can turn the
read-mod-write cycle into a read, increment, write as 3 instructions with
better scheduling opportunities.
That way we get the benefit of better scheduling/pairing without adding
register pressure to the port and causing spills.
We've got a lot of the infrastructure in the compiler now -- most importantly
the post-reload life analysis pass. It's just waiting for someone to take
up the task.
jeff