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: Alan Lehotsky <apl at alum dot mit dot edu>
- Cc: Peter Barada <pbarada at mail dot wm dot sps dot mot dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 14 Jun 2002 16:07:13 -0600
- Subject: Re: Missed optimization in m68k
- Reply-to: law at redhat dot com
In message <a05111a1ab9300f873826@[63.214.71.88]>, Alan Lehotsky writes:
> At 3:16 PM -0600 6/14/02, law@redhat.com wrote:
> >In message <a05111a19b9300913b4e9@[63.214.71.88]>, Alan Lehotsky writes:
> > > At 1:48 PM -0600 6/14/02, law@redhat.com wrote:
> > > >In message <200206141923.g5EJNeK22444@hyper.wm.sps.mot.com>, Peter
> > > >Barada write
> > ..... > > > copy:
> > > > > move.l 4(%sp),%a1
> > > > > move.l 8(%sp),%a0
> > > > > move.l %a0,%d0
> > > > > .L2:
> > > > > move.b (%a1)+,(%a0)+
> > > > > jbne .L2
> > > > > rts
> > > > >
> > > > > Thanx...
> > > >I believe you'll be hacking in NOTICE_UPDATE_CC.
> > > >
> > > >jeff
> > >
> > >
> > > In this case, I suspect that a DEFINE_PEEPHOLE is probably better!
> >I don't think so -- the whole point behind NOTICE_UPDATE_CC is to be
> >able to eliminate useless tst insns because the cc value happens to
> >be lying around due to an earlier load/store or arithmetic instruction.
> >
>
> But the TST isn't useless - it has a side-effect of
> postincrementing the pointer.
Ahhh. Silly me. You're right. This is kind-of a pain to fix right;
peepholes may be the answer.
jeff