Comment 1:

ruiu, you recently did some rex prefix tinkering in 6a. I don't suppose you want to
tackle this one as well? (If not, I'll do it.)

Comment 2:

Feel free to assign it to me.

Comment 3:

Owner changed to @rui314.

Comment 4:

Actually, it turns out this is blocking me, so unless you've started on it already, I
might do it. Please let me know.

Comment 5:

I haven't started this yet. Sorry about that. You can take it.

Comment 6:

No need to apologize! I didn't know I'd need it so soon.
I managed to hack in a horrible workaround that will unblock me (CL 125510043). I'd
still love your help with this, though, since it's not clear to me what the right fix is.
The problem is that SETxx is not marked as working on byte registers. We could convert
automatically from (say) AX to AL during encoding, but I don't know whether that will
cause problems elsewhere. (Incorrect expectation that AH will be cleared? False
aliasing?) We could insist that that SETxx be given a byte register explicitly, and
maybe rename them to SETBxx, although that will be a bit more annoying during codegen.
Input requested.
FWIW, CL 125510043 does the former:
$ cat x.s
TEXT ·TestSetCC(SB),$0
    SETEQ ,BPB
    SETEQ ,BP
    SETEQ ,CH
    SETEQ ,CL
    SETEQ ,CX
$ go tool 6a -S x.s
"".TestSetCC t=1 size=32 value=0 args=0xffffffff80000000 locals=0x0
    0x0000 00000 (rex.s:1)  TEXT    "".TestSetCC+0(SB),4,$0--2147483648
    0x0000 00000 (rex.s:2)  SETEQ   ,BPB
    0x0004 00004 (rex.s:3)  SETEQ   ,BPB
    0x0008 00008 (rex.s:4)  SETEQ   ,CH
    0x000b 00011 (rex.s:5)  SETEQ   ,CL
    0x000e 00014 (rex.s:6)  SETEQ   ,CL
    0x0000 40 0f 94 c5 40 0f 94 c5 0f 94 c5 0f 94 c1 0f 94  @...@...........
    0x0010 c1                                               .
Note that BP is mapped to BPB, CX is mapped to CL, and rex prefixes are applied
appropriately.

Comment 7:

Here's my two cents. First of all, SETEQ AH/BH/CH/DH is an illegal combination of the
instruction and the operand, no? It's not encodable in x86-64. I think we should just
reject it. Besides that, I'd think we want to write something like SETEQ AX (or whatever
the generic name of a register) rather than SETEQ AL, just like we usually write MOVB AX
rather than MOVB AL.
Thinking about that, it feels just fine to me if SETCC modifies only the least
significant byte in the register. MOVB and such work that way, and the only way to know
if an instruction works on a byte register is its instruction name. Usually B suffix
implies that, but I believe there are some exceptions. As long as the user remembers the
SETCC instructions work on a byte register, it should be fine.
Is your concern on the possible problems real? I mean, if the instructions are currently
encoded into wrong byte sequences, I assume nobody is actually using it. If no one is
using it, do you have to worry about them?

Comment 8:

All SGTM, although I'm (clearly) not the right person to make the call. :)

Comment 10:

Labels changed: added release-go1.5, removed release-go1.4.

Interestingly, cmd/8a encode SETE BP as:
87 dd 0f 94 c3 87 dd

i.e. it synthesizes sete bp as:
xchgl %ebx, %ebp
sete %bl
xchgl %ebx, %ebp

so it seems cmd/8a is not affected by this (and it's pretty
clever in encoding the invalid instruction.)