This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Missed optimization in m68k
- From: law at redhat dot com
- To: Peter Barada <pbarada at mail dot wm dot sps dot mot dot com>
- Cc: apl at alum dot mit dot edu, Peter dot Barada at motorola dot com, gcc at gcc dot gnu dot org
- Date: Sun, 23 Jun 2002 10:20:42 -0600
- Subject: Re: Missed optimization in m68k
- Reply-to: law at redhat dot com
In message <200206142334.g5ENYfQ23954@hyper.wm.sps.mot.com>, Peter Barada
writes:
> I'll assume that this is a regression from a previous version(how far
> back I don't have a clue). I'll look at a peephole2 to see if it
> solves the problem, and at that point submit a patch relative to 3.0.4
> for gcc/config/m68k/m68k.md
>
> Since you've got my attention, what's the real solution that you're
> thinking about instead of the peephole I'll implement for the moment
> to get around it....
Well, in simplest terms, you want to try and avoid having the autoincrement
on the test insn unless there is a. nowhere else to put it and b. the test
insn is not redundant with some previous insn.
a. would require the ability to have multiple candidates for creating
autoincrement expressions and would probably require the ability to update
the test if the autoincrement is placed on a previous insn. Nontrivial.
b. would require us to know at autoincrement generation time that the test
is likely to be eliminated. Also rather difficult.
Another approach would be to have code which knows how to look at a mostly
redundant test, split out any side effects we must keep, reattach those side
effects to another insn, then delete the test. This may or may not be
easier to codify.
jeff