On Wed, Aug 12, 2026 at 3:30 PM H.J. Lu <[email protected]> wrote: > > On Wed, Aug 12, 2026 at 1:15 PM Hongtao Liu <[email protected]> wrote: > > > > 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. > > Changed to register_operand in v4. > > > 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. > > I replaced them with > > ;; AVX capable processors from Intel, AMD, Hygon and Zhaoxin guarantee > ;; that 128-bit aligned vector loads and stores are atomic. > > Here is the v4 patch. OK for master if there are no regressions? LGTM.
> > Thanks. > > -- > H.J. -- BR, Hongtao
