Ping. Thanks, Soumya
> On 24 Feb 2026, at 11:57 AM, Soumya AR <[email protected]> wrote: > > Hi, > > I'm working on implementing support for C++26 atomic reductions in GCC. > > Corresponding paper for this: > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3111r8.html > > I'd like to get some insight into the preferable builtin interface. As I see > it, > we have the following options: > > Option 1 (that we expect to implement): One generic builtin per new operation > > We add the generic builtin for each new operation and resolve it in the > middle-end later. This is similar to the atomic int fetch_min/max > implementation > in this patch: > > https://gcc.gnu.org/pipermail/gcc-patches/2026-January/706242.html > > This would result in 7 new builtins, 1 for each new operation. > > Option 2: Explicit builtins per operation and their types: > > This would follow the existing pattern and add a new family of builtins. > Assuming we name them __atomic_store_<op>, we would have: > __atomic_store_add, > __atomic_store_sub, > __atomic_store_and, > __atomic_store_or, > __atomic_store_xor, > __atomic_store_max, > __atomic_store_min, > and all of their typed variants (_N, _1, _2, _4, _8, _16), resulting in 42 new > builtins. > > However, this would again result in the earlier issue of a builtin explosion > wrt integer fetch min/max discussed here: > https://gcc.gnu.org/pipermail/gcc-patches/2025-November/699602.html > > Option 3: Extend existing __atomic_fetch_* builtins > > Add a parameter to the existing __atomic_fetch_* builtins to choose their > no-read / reduction variant. > > Although this leads to no new builtins added, the name fetch_* would become a > misnomer for these and lead to a confusing user interface. > > Would appreciate some feedback on what would be the best step forward here for > GCC. Will accordingly get feedback from the LLVM community on this as well. > > Best, > Soumya >
