[committed] i386: Use lock prefixed insn instead of MFENCE [PR95750]

[Franz Sirl]

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  <ubizjak@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