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, [email protected] wrote:
From: Soumya AR <[email protected]>
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?
