Missed optimization in m68k

[law@redhat.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