Am 2020-07-20 um 20:39 schrieb Uros Bizjak via Gcc-patches:
Currently, __atomic_thread_fence(seq_cst) on x86 and x86-64 generates
mfence instruction. A dummy atomic instruction (a lock-prefixed instruction
or xchg with a memory operand) would provide the same sequential consistency
guarantees while being more efficient on most current CPUs. The mfence
instruction additionally orders non-temporal stores, which is not relevant
for atomic operations and are not ordered by seq_cst atomic operations anyway.

2020-07-20  Uroš Bizjak  <ubiz...@gmail.com>

gcc/ChangeLog:
     PR target/95750
     * config/i386/i386.h (TARGET_AVOID_MFENCE):
     Rename from TARGET_USE_XCHG_FOR_ATOMIC_STORE.
     * config/i386/sync.md (mfence_sse2): Disable for TARGET_AVOID_MFENCE.
     (mfence_nosse): Enable also for TARGET_AVOID_MFENCE. Emit stack
     referred memory in word_mode.
     (mem_thread_fence): Do not generate mfence_sse2 pattern when
     TARGET_AVOID_MFENCE is true.
     (atomic_store<mode>): Update for rename.
     * config/i386/x86-tune.def (X86_TUNE_AVOID_MFENCE):
     Rename from X86_TUNE_USE_XCHG_FOR_ATOMIC_STORE.

gcc/testsuite/ChangeLog:
     PR target/95750
     * gcc.target/i386/pr95750.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.


Hi,

I didn't bisect it, but I see a profiledbootstrap ICE that may be related:

libtool: compile: /home/fsirl/rpmbuild/BUILD/gcc-11.0.0+gitr11+2246/obj-x86_64-suse-linux/./gcc/xgcc -B/home/fsirl/rpmbuild/BUILD/gcc-11.0.0+gitr11+2246/obj-x86_64-suse-linux/./gcc/ -B/usr/x86_64-su se-linux/bin/ -B/usr/x86_64-suse-linux/lib/ -isystem /usr/x86_64-suse-linux/include -isystem /usr/x86_64-suse-linux/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../libgo -I ../../../../libgo/runti me -I../../../../libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual -minline-all-stri ngops -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../../libgo/../libgcc -I ../../../../libgo/../libbacktrace -I ../../../gcc/include -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE= 2 -funwind-tables -fasynchronous-unwind-tables -U_FORTIFY_SOURCE -m32 -MT runtime/runtime_c.lo -MD -MP -MF runtime/.deps/runtime_c.Tpo -c ../../../../libgo/runtime/runtime_c.c -fPIC -DPIC -o runtime
/.libs/runtime_c.o
../../../../libgo/runtime/runtime_c.c: In function ?runtime_cputicks?:
../../../../libgo/runtime/runtime_c.c:102:1: error: unrecognizable insn:
  102 | }
      | ^
(insn 20 19 21 6 (set (mem/v:BLK (scratch:SI) [0  A8])
        (unspec:BLK [
                (mem/v:BLK (scratch:SI) [0  A8])
] UNSPEC_MFENCE)) "../../../../libgo/runtime/runtime_c.c":84:7 -1
     (nil))
during RTL pass: vregs
../../../../libgo/runtime/runtime_c.c:102:1: internal compiler error: in extract_insn, at recog.c:2294

This is on a Xeon X5650 machine.

Franz

Reply via email to