On Mon, Jul 1, 2024 at 4:51 AM Richard Henderson <[email protected]> wrote: > While debugging #2413, I spent quite a bit of time trying to work > out if the CCOp value was incorrect. I think the following is a > worthwhile cleanup, isolating potential problems to asserts.
Hi Richard, no objections at all to introducing more asserts. I think keeping the array is a better underlying implementation for cc_op_live() however. I'm also not very fond of mixing "sized" and "unsized" CCOps in the 4..7 range, there's no real reason why CC_OP_DYNAMIC and CC_OP_CLR must be close to CC_OP_EFLAGS and the ADCOX CCOps. I also think it's clearer to keep CC_OP_POPCNT[BWLQ] (even though in practice only one will be used because popcnt needs zero extension anyway). As an aside, I'm wondering if CC_OP_CLR is particularly important; I expect "xor reg, reg" to be followed by more ALU operations most of the time and to not be followed by a jump, so it only saves a spill if xor reg, reg is followed by a lot or store. If gen_XOR used either CC_OP_LOGICn or CC_OP_EFLAGS for "xor reg, reg", the values in decode->cc_op_* (CC_OP_DST=0 for CC_OP_LOGICn; CC_OP_SRC=CC_Z|CC_P for CC_OP_EFLAGS) would be constant and wouldn't add to register pressure. Paolo
