Re: [cxx-mem-model] compare_exchange implementation

[Richard Henderson <rth at redhat dot com>]

On 10/19/2011 09:26 AM, Andrew MacLeod wrote:
> well, they are explicitly    'compare_exchange_strong'  and 'compare_exchange_weak' calls...   so yes, they have 'hardcoded' one or the other :-)
> we could alternatively do 2 separate builtins, but I didn't see the point.  But Im ambivalent.  

I'm just not keen on issuing errors this late.  If we 'know' it's always going to
be 0/1 because of other things the compiler does, we might as well simply do

	weak = (opN == const1_rtx)

and leave it at that.

> I clearly misunderstood what you said then, I thought you said use
> QImode :-P.   So, look at target and use that mode?  target may not
> be set sometimes tho right? what do you use then?  QImode?

You never look at target, you look at 

	insn_data[icode].operand[opno].mode

if target is set and doesn't match that mode, then create a new pseudo
of the proper mode and let your caller do the conversion.

> If I understand my previous conversation with Lawrence, we need to
> know what mode the native CAS is.

We don't have that knowledge for any of the other rtl patterns; we
ask the rtl pattern to enforce a given mode.  We should do the same
for CAS.

> Worst case, if the native CAS is relaxed, the fences need to be
> issued as such to implement
> 
>  compare_exchange (T* ptr, T* old, new, success, failure)
> 
>     memory_fence (success)         // release modes
>     val = *old;
>     res = relaxed_CAS (ptr, val, new)
>     if (success)
>       {
>         memory_fence (success);   // acquire modes
>         return true;
>       }
>     *old = res;
>     memory_fence (failure)  
>     return false;

If the target uses LL/SC, then native CAS is likely relaxed.  However,
we will already be emitting a number of jumps in order to implement
the LL/SC sequence and stuffing the fences into those jumps is going
to be much better than you trying to do it in the middle-end outside
of that sequence.  Really.

> So if the CAS can handle it all, why does it matter if the pattern
> has a single "compressed" parameter for the 3 values, or whether it
> simply explicitly lists all three?

*shrug* Just for less memory consumption.  It *could* remain 3 values.


r~