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))]
""
...
>
> +(define_expand "atomic_storeti"
> + [(set (match_operand:TI 0 "memory_operand")
> + (unspec:TI [(match_operand:TI 1 "nonimmediate_operand")
> + (match_operand:SI 2 "const_int_operand")]
> + UNSPEC_STA))]
> + "TARGET_128BIT_ATOMIC_ENABLED"
> +{
> + /* Use V1TImode to force vector register for atomic store. */
> + rtx src = gen_reg_rtx (V1TImode);
> + rtx op1 = gen_lowpart (V1TImode, operands[1]);
> + emit_move_insn (src, op1);
> + emit_insn (gen_atomic_storeti_sse (operands[0], src));
> + DONE;
> +})
> +
> Other atomic store handles sequentially consistent stores with a fence. .i.e
>
> /* ... followed by an MFENCE, if required. */
> if (is_mm_seq_cst (model))
> emit_insn (gen_mem_thread_fence (operands[2]));
> DONE;
>
> Do we need a similar handle for atomic_storeti?
>
Fixed.
I am testing in the v3 patch and will submit when it is
done.
--
H.J.
