On Tue, Jul 21, 2026 at 4:01 PM H.J. Lu <[email protected]> wrote:
>
> On Tue, Jul 21, 2026 at 3:45 PM Florian Weimer <[email protected]> wrote:
> >
> > * H. J. Lu:
> >
> > > With the silicon vendor guarantees from Intel, AMD, Hygon and Zhaoxin in:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
> > >
> > > many software developers would happily use inline 128-bit atomic loads
> > > and stores in their programs because they only target compatible CPUs.
> > > Add -m128bit-atomic to generate 128-bit atomic loads and stores to avoid
> > > the overhead of calling into libatomic.  Enable -m128bit-atomic by default
> > > if supported by the targeting processor, which is one of x86-64-v3 capable
> > > processors as well as AVX capable processors from Intel, AMD, Hygon and
> > > Zhaoxin, with SEE2 and CMPXCHG16B enabled.
> > >
> > > gcc/
> > >
> > > PR target/94649
> >
> > This patch doesn't seem to produce lock cmpxchg16b for the reproducer in
> > PR94649 with just -mcx16.  I don't think this optimization needs full
> > 128-bit atomics, just lock cmpxchg16b support is enough.
>
> -mcx16 alone won't generate "lock cmpxchg16b".  My patch doesn't change
> atomic_compare_and_swap patterns.  It only added atomic_loadti and
> atomic_storeti.  I goess "lock cmpxchg16b" needs atomic_loadti and
> atomic_storeti somehow.

Yes, they are needed:

Breakpoint 1.1, direct_optab_handler (op=atomic_load_optab, mode=E_TImode)
    at /export/gnu/import/git/gitlab/x86-gcc/gcc/optabs-query.h:67
67   return optab_handler (op, mode);
(gdb) bt
#0  direct_optab_handler (op=atomic_load_optab, mode=E_TImode)
    at /export/gnu/import/git/gitlab/x86-gcc/gcc/optabs-query.h:67
#1  0x0000000002be9acd in can_atomic_load_p (mode=E_TImode)
    at /export/gnu/import/git/gitlab/x86-gcc/gcc/optabs-query.cc:680
#2  0x0000000002bdfac2 in expand_atomic_compare_and_swap (
    ptarget_bool=0x7fffffffb1f8, ptarget_oval=0x7fffffffb210,
    mem=0x7fffe8f0b018, expected=0x7fffe8f0b0d8, desired=0x7fffe8f04f48,
    is_weak=true, succ_model=MEMMODEL_SEQ_CST, fail_model=MEMMODEL_SEQ_CST)
    at /export/gnu/import/git/gitlab/x86-gcc/gcc/optabs.cc:7534
#3  0x000000000258762f in expand_builtin_atomic_compare_exchange (
    mode=E_TImode, exp=0x7fffe8efa480, target=0x7fffe8f04c00)
    at /export/gnu/import/git/gitlab/x86-gcc/gcc/builtins.cc:6759

>
> > > +@opindex m128bit-atomic
> > > +@item -m128bit-atomic
> > > +Generate cmpxchg16b, 128-bit atomic vector load and store instructions.
> > > +This is safe to use only on x86-64-v3 capable processors as well as AVX
> > > +capable processors from Intel, AMD, Hygon and Zhaoxin, which guarantee
> > > +that 128-bit aligned vector loads and stores are atomic.  This option
> > > +is enabled by default if supported by the targeting processor with
> > > +SEE2 and CMPXCHG16B enabled.
> >
> > This could reference -mcx16.
> >
>
> It mentions CMPXCHG16B.  How should it be phrased?
>
>
> --
> H.J.



-- 
H.J.

Reply via email to