Questions about CompareAndSwap

[Roman Kennke]

> 1. Why do we do:
> 
> cmpxchgq
> sete
> movzbl

Ok, I think I figured out the answer to that first question.
ConditionalStoreP can feed directly into a BoolNode, while
CompareAndSwapP must go through a CmpINode first.

I wonder if the CompareAndSwapP can be done like ConditionalStoreP,
with a CMove attached to it, and attempt to optimize away a
CompareAndSwapP->Bool->CMove->CmpI->Bool chain (which would be the
result of normal use-cases of CompareAndSwapP I guess) into
CompareAndSwapP->Bool ? Thus resulting in a direct use of the flags.

What do you think?

Roman

> 
> I.e. do the CAS, then set 1 in the result register if ZF was set,
> then
> mask? A few lines up I see storePConditional, which does (to my eyes)
> *exactly* the same, except that it actually passes out the flags?
> 
> It says there 'no flag versions of CompareAndSwap{P,I,L} because
> matcher can't match them' but why does it work for StorePConditional?
> 
> 2. Would it be possible to also get the actual old-value out of
> CompareAndSwapP, in addition to the flags? My idea is that
> CompareAndSwapP would be a MultiNode producing two outputs. Would
> that
> be possible? Would there be any disadvantages (i.e. loss of
> performance
> due to messed up optimizations, or such?)
> 
> 
> In case you wonder why I need this, I need to do some special tricks
> to
> make CompareAndSwapP work correctly with Shenandoah, where an object
> can have a from-space and a two-space copy. I have an algorithm that
> works and is efficient enough, but it requires to get the previous
> value of the memory location. Currently I do this using an extra
> LoadP,
> but I guess it might be more efficient to use what I get out of the
> cmpxchg?
> 
> Cheers,
> Roman
>