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*
+ 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.
+Variable
+int ix86_flags = 0
Can we reuse ix86_target_flags, m128bit-atomic only need one bit.
+(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?
+(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?
--
BR,
Hongtao
