[PATCH 1/8] builtin: Add builtin types and function declarations for integer atomic fetch min/max

[Matthew Malcomson]

On 9/2/25 09:19, Jakub Jelinek wrote:
> External email: Use caution opening links or attachments
> 
> 
> On Tue, Sep 02, 2025 at 12:03:59PM +0530, soumyaa@nvidia.com wrote:
>> From: Soumya AR <soumyaa@nvidia.com>
>>
>> This patch adds builtin types and function declarations for integer atomic fetch
>> min/max operations.
> 
> Do we really need the new builtins?
> Isn't it better to just pattern recognize such operations using
> __atomic_compare_exchange if the given optab exists on the target?
> When pattern recognized it can then just use one internal fn to represent
> all of these.
> 
>          Jakub
> 

Ah -- to be honest we never considered this seriously due to how we came 
to this work.

The implicit reason in how we made the decision is:
- Using pattern matching would mean libstdc++ will be using the CAS loop 
to implement these new C++ methods.
- We've seen other compilers have a lot of trouble recognising CAS loops 
in that context and turning that into a builtin (NVC++ had trouble with 
suboptimal codegen due to finding it hard to pattern-match the libstdc++ 
floating point fetch_add and fetch_sub CAS loop).
- Hence we'd like the builtins so that libstdc++ can use them.  That 
should mean that it's easier for other compilers to generate good code.


Attempting to distill what the difficulty was w.r.t. recognising CAS 
loops in libstdc++ (the motivating example for us):
- The load and compare exchange used in CAS loops there are behind a 
local function call to add some assertions and type-safety.  Pattern 
matching this can get quite difficult.
- These C++ operations will also have floating point variants, and CAS 
loops written to emulate them would require handling the floating point 
semantics (and exception information) "just right" in order to be able 
to be replaced by the relevant operation.

Does that sound reasonable?