[PATCH] [RFC] Lame fix for PR20376

[Tim Northover]

>> But I'm not sure that actually affects the best solution here. I rather suspect performing the comparison again would be quicker in general. I suppose the question is how common and performance-critical such fragments are.
>
> I don't understand this point. Compare exchanges are not idempotent.

Ah, sorry. I was biased by my recent work there. There's a
CMPXCHG_WITH_SUCCESS DAG node now which represents what used to be a
cmpxchg followed by an icmp against the old value for success.

x86 deals with these directly and may not even create a SETCC-like
node in the first place. So in this case, I suspect cmpxchg/cmp would
be better than cmpxchg/pushf/pop/push/popf (or even the lahf/sahf
one).

But as before, it's mostly only relevant if we expect this to be a common case.

Cheers.

Tim.