No, setcc actually does depend on the previous value of the register, because it only comes in the low-byte variants (i.e. al, bl, cl, dl etc)--the top 7 bytes of the destination are left unmodified.

A one-instruction variant I've seen that gets you the negated value of the carry flag is sbb rax, rax. This doesn't depend on the previous value of rax in a mathematical sense, though I'm unsure if it depends in an out-of-order sense; that is, if it's recognized as a zeroing idiom (or rather, zeroing or all-one-ing in this case). Probably not.

EDIT: did a quick test, and sbb rax, rax etc are not recognized to be a zeroing idiom, at least on my old Haswell. So it's still one instruction, but has a dependency on the previous register value.

> setcc actually does depend on the previous value of the register, because it only comes in the low-byte variants

You should be able to break the dependency and avoid the partial register stall by doing: movzx eax, ax

See: https://stackoverflow.com/questions/41573502/why-doesnt-gcc-... ; https://software.intel.com/en-us/forums/intel-isa-extensions... ; https://www.agner.org/optimize/microarchitecture.pdf (section 6.8)

You're right, but only for pre-Haswell chips, where al etc. are renamed separately. From Haswell onwards, they aren't, and depend on the old value. So movzx eax, al gets you mathematical independence, but not out-of-order independence. There's a bunch more detail in this Stack Overflow question (referenced in the one you linked): https://stackoverflow.com/questions/45660139/how-exactly-do-...