i386 string compare - code quality regression from 2.95

[Zack Weinberg]

> > > Remove the constraints here; they are unused.
> > 
> > I'm not sure what you mean.  All of them, or just the register
> > selections on the clobbers, or what?
> 
> All of them.

So this would be the correct pattern?

  [(parallel[
     (set (reg:CC 17)
	  (compare:CC (mem:BLK (match_operand:SI 4 "register_operand" ""))
		      (mem:BLK (match_operand:SI 5 "register_operand" ""))))
     (use (match_operand:SI 6 "register_operand" ""))
     (use (match_operand:SI 3 "immediate_operand" ""))
     (use (reg:SI 19))
     (clobber (match_operand:SI 0 "register_operand" ""))
     (clobber (match_operand:SI 1 "register_operand" ""))
     (clobber (match_operand:SI 2 "register_operand" ""))])
   (set (match_operand:QI 7 "register_operand" "")
	(gtu:QI (reg:CC 17) (const_int 0)))
   (set (match_operand:QI 8 "register_operand" "")
	(ltu:QI (reg:CC 17) (const_int 0)))
   (set (reg:CCZ 17)
	(compare:CCZ (match_dup 7) (match_dup 8)))
  ]

This could use some clarification in md.texi, it doesn't say anything
about what match_operand expressions in peephole2's are supposed to
look like.

As long as you're here, I think the modes on the final set expression
are too strict; I believe it's correct in this context to accept any
of the integer CC modes in the final set, since the initial compare
gives us a complete condition code, but I don't know how to express
that.  Grepping through libbackend.a, we seem to have missed a few
instances where the peephole should have matched, and I bet this is
why.  Any suggestions?  Could I get away with leaving out the modes
altogether?

-- 
zw              But the voices in my head are what keeps me sane.
                	-- Shweta Narayan