Swap the compare operands if LHS is spilled while updating the CCMask:s of the CC users.
This is relatively straight forward if the live-in lists for non-allocatable registers (CC) are assumed to be correct during register allocation. The experimental verifyLiveInLists_CC() has not detected any missing CC in any live-in lists so far, but this is still a missing piece to add if this is found useful enough.
On SPEC 2006, I see:
cg : 10184 10861 +677 lg : 373873 373204 -669 je : 118876 119381 +505 cgrje : 19726 19301 -425 c : 17535 17941 +406 l : 73704 73319 -385 jlh : 61456 61810 +354 cgrjlh : 11370 11189 -181 crjlh : 9502 9353 -149 crje : 6488 6406 -82 jle : 12939 13000 +61 crjhe : 3843 3787 -56 cgr : 1805 1754 -51 crjle : 2508 2462 -46 jhe : 10908 10953 +45 lr : 27011 26967 -44
I interpret this to mean that this patch handles some additional ~1000 cases. This seems to mean that the compare is now folded with the load load instead of with the jump, like 'lg; cgrje' => 'cg; je'. I am not sure this is really better, then? Would it be worth the trouble of adding some kind of live-in lists check before regalloc for non-allocatable phys reg(s)?
I'm not sure it is safe to assert here. If there's no CC users of a compare, then the compare is dead and will usually have been optimized away. But I'm not sure we can fully rely on that to have happened in all cases (e.g. what about -O0?).