Re: Missed optimization in m68k

[Alan Lehotsky <apl at alum dot mit dot edu>]

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.

	You can only eliminate the test if you fix the MOVE to do the 
post increment itself,
	and the move has been emitted into the .s file....