[PATCH] [RFC] Lame fix for PR20376

Tim Northover 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 mailing list