RFR: 8186838: Generalize Atomic::inc/dec with templates

[Robbin Ehn]

Hi,

On 09/02/2017 10:31 AM, Andrew Haley wrote:
> On 01/09/17 15:15, Erik Österlund wrote:
>> It is not the simplest solution I can think of. The simplest solution I
>> can think of is to remove all specialized versions of Atomic::inc/dec
>> and just have it call Atomic::add directly. That would remove the
>> optimizations we have today, for whatever reason we have them. It would
>> lead to slightly more conservative fencing on PPC/S390,
> 
> I see.  Can you say what instructions would be different?
> 
>> and would lead to slightly less optimal machine encoding on x86
>> (without immediate values in the instructions). But it would be
>> simpler for sure. I did not put any judgement into whether our
>> existing optimizations are worthwhile or not. But if you want to
>> prioritize simplicity, removing those optimizations is one possible
>> solution. Would you prefer that?
> 
> Is this really about optimization?  If we cared about getting this
> stuff as optimized as possible we'd use intrinsics on GCC/x86 targets.
> These have been supported for a long time.  But it seems we're
> determined to preserve the legacy assembly-language implementations
> and use them everywhere, even where they are not necessary.
> 

Why not use gcc/clang intrinsic on for all platforms we use gcc/clang? (not just gcc/x86)
For "__atomic_fetch_add (&value, inc, __ATOMIC_RELAXED);"
gcc seem to generate "lock addl" on x86 and armv8 ldxr,stxr, with acq_rel ldaxr,stlxr, which is what I would expect.

And thus we can remove a lot of code!

(if we should have the relaxed version in API is another question)

/Robbin