CL 112570044 introduces a JMP into the middle of slicing, which disrupts some peephole
optimization. See the CL discussion for details.

We could fix this by introducing architecture-dependent branch-free ternary ops.

Here are a couple of tested (6g) implementations of the particular function that slicing
needs. Their performance is about the same.

// eq0 returns 0 if i == j and i otherwise.
func eq0(i, j int) int {
    if i == j {
        return 0
    }
    return i
}

TEXT ·eq0(SB),$0
    MOVQ    i+0(FP),AX
    CMPQ    AX,j+8(FP)
    SETEQ   CX
    DECQ    CX
    ANDQ    AX, CX
    MOVQ    CX,r+16(FP)
    RET ,

TEXT ·eq0(SB),$0
    MOVQ    i+0(FP),AX
    MOVQ    $0,CX
    CMPQ    AX,j+8(FP)
    CMOVQNE AX,CX
    MOVQ    CX,r+16(FP)
    RET ,

I'm not sure that this is worth the effort in the near term, though, unless there are
other places that also would benefit from branch-free ?:.