On Wed, Aug 12, 2026 at 7:59 AM H.J. Lu <[email protected]> wrote:
>
> On Tue, Aug 11, 2026 at 7:15 PM H.J. Lu <[email protected]> wrote:
> >
> > On Tue, Aug 11, 2026 at 11:32 AM Hongtao Liu <[email protected]> wrote:
> > >
> > > On Wed, Jul 22, 2026 at 2:24 PM H.J. Lu <[email protected]> wrote:
> > > >
> > > > Changes in v2:
> > > >
> > > > 1. Add TARGET_128BIT_ATOMIC_ENABLED.
> > > > 2. Remove __atomic Builtins reference from -mcx16.
> > > > 3. Update -m128bit-atomic documentation.
> > > > 4. Issue an error for -m128bit-atomic with -m32.
> > > >
> > > > --
> > > > H.J.
> > > > --
> > > > 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 in
> > > > 64-bit
> > > > mode 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.
> > > >
> > > > gcc/
> > > >
> > > > PR target/94649
> > > > PR target/126293
> > > > * common/config/i386/i386-cpuinfo.h (ix86_decode_cpu_info): New
> > > > function.
> > > > * config/i386/i386-options.cc
> > > > (ix86_option_override_internal): Issue an error for -m128bit-atomic
> > > > in 32-bit mode. Turn on -mcx16 if -m128bit-atomic is enabled.
> > > > Enable -m128bit-atomic in 64-bit mode by default if supported by
> > > > the targeting processor.
> > > > * config/i386/i386.h (TARGET_128BIT_ATOMIC_ENABLED): New.
> > > > * config/i386/i386.opt (ix86_flags): New Variable.
> > > > (m128bit-atomic): New option.
> > > > * config/i386/i386.opt.urls: Regenerated.
> > > > * config/i386/sync.md (atomic_loadti): New pattern.
> > > > (atomic_loadti_sse): Likewise.
> > > > (atomic_storeti): Likewise.
> > > > (atomic_storeti_sse): Likewise.
> > > > * doc/invoke.texi: Remove __atomic Builtins reference from -mcx16.
> > > > Document -m128bit-atomic.
> > > >
> > >
> > > + || (subtype >= INTEL_COREI7_GRANITERAPIDS
> > > + && subtype <= INTEL_COREI7_PANTHERLAKE)
> > > + || subtype == INTEL_COREI7_DIAMONDRAPIDS
> > > + || subtype <= INTEL_COREI7_NOVALAKE)
> > > + {
> > > + vendor = VENDOR_INTEL;
> > > + type = INTEL_COREI7;
> > > + }
> > > || substype <= INTEL_COREI7_NOVALAKE classifies AMD/Zhaoxin CPUs as
> > > Intel, is it a typo of *subtype == NTEL_COREI7_NOVALAKE*
> >
> > Fixed.
> >
> > >
> > > + if (TARGET_128BIT_ATOMIC_P (opts->x_ix86_flags))
> > > + {
> > > + if (!TARGET_64BIT_P (opts->x_ix86_isa_flags))
> > > + error ("%<-m128bit-atomic%> not supported for 32-bit code");
> > > + else if (!TARGET_CX16_P (opts_set->x_ix86_isa_flags2))
> > > + {
> > > + /* Enable CMPXCHG16B when -m128bit-atomic is enabled. */
> > > + opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA2_CX16;
> > > + }
> > > + }
> > >
> > > With global -march=skylake, a function marked target("arch=x86-64")
> > > still emits movdqa atomic loads. The non-explicit bit needs clearing
> > > before deriving the default for each target option set.
> >
> > Fixed.
> >
> > > +Variable
> > > +int ix86_flags = 0
> > >
> > > Can we reuse ix86_target_flags, m128bit-atomic only need one bit.
> >
> > Fixed.
> >
> > > +(define_expand "atomic_loadti"
> > > + [(set (match_operand:TI 0 "nonimmediate_operand")
> > > + (unspec:TI [(match_operand:TI 1 "memory_operand")
> > > + (match_operand:SI 2 "const_int_operand")]
> > > + UNSPEC_LDA))]
> > > + "TARGET_128BIT_ATOMIC_ENABLED"
> > > +{
> > > + emit_insn (gen_atomic_loadti_sse (operands[0], operands[1]));
> > > + DONE;
> > > +})
> > >
> > > change operands[0] from nonimmediate_operand to register_operand?
> >
> > It is done on purpose the same way as
> >
> > (define_expand "atomic_load<mode>"
> > [(set (match_operand:ATOMIC 0 "nonimmediate_operand")
> > (unspec:ATOMIC [(match_operand:ATOMIC 1 "memory_operand")
> > (match_operand:SI 2 "const_int_operand")]
> > UNSPEC_LDA))]
> > ""
This one either generates atomic_loaddi_fpu which supports
memory_operand for operands[0], or manually handles memory operand for
operands[0].
But atomic_loadti expander directly generates atomic_loadti_sse which
will hit unrecognized insn when operands[0] is memory_operand. For
simplicity, maybe change nonimmediate_operand to register_operand.
169 /* For DImode on 32-bit, we can use the FPU to perform the load. */
170 if (<MODE>mode == DImode && !TARGET_64BIT)
171 emit_insn (gen_atomic_loaddi_fpu
172 (operands[0], operands[1],
173 assign_stack_temp (DImode, GET_MODE_SIZE (DImode))));
174 else
175 {
176 rtx dst = operands[0];
177
178 if (MEM_P (dst))
179 dst = gen_reg_rtx (<MODE>mode);
180
181 emit_move_insn (dst, operands[1]);
182
183 /* Fix up the destination if needed. */
184 if (dst != operands[0])
185 emit_move_insn (operands[0], dst);
>153;; Importantly, *no* processor makes atomicity guarantees for larger
>154;; accesses. In particular, there's no way to perform an atomic TImode
>155;; move, despite the apparent applicability of MOVDQA et al.
We may need to change the comments in sync.md:153 after 128-bit atomic
load is supported.
--
BR,
Hongtao
