[PATCH] [RFC] Lame fix for PR20376
t.p.northover at gmail.com
Tue Jul 22 12:03:07 PDT 2014
>> 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
But as before, it's mostly only relevant if we expect this to be a common case.
More information about the llvm-commits