[all-commits] [llvm/llvm-project] b33432: [X86] Prefer `lock or` over mfence (#106555)

[Valentin Churavy via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b334321678d4df2d8b1572301c827cae4d4097e2
      https://github.com/llvm/llvm-project/commit/b334321678d4df2d8b1572301c827cae4d4097e2
  Author: Valentin Churavy <v.churavy at gmail.com>
  Date:   2025-03-11 (Tue, 11 Mar 2025)

  Changed paths:
    M llvm/lib/Target/X86/X86ISelLowering.cpp
    M llvm/lib/Target/X86/X86Subtarget.h
    M llvm/test/CodeGen/X86/atomic-idempotent.ll
    M llvm/test/CodeGen/X86/atomic-unordered.ll
    M llvm/test/CodeGen/X86/implicit-null-check.ll
    M llvm/test/CodeGen/X86/membarrier.ll
    M llvm/test/CodeGen/X86/mfence.ll

  Log Message:
  -----------
  [X86] Prefer `lock or` over mfence (#106555)

Originally discussed in https://reviews.llvm.org/D129947

LLVM currently emits `mfence` for `__atomic_thread_fence(seq_cst)`. On
modern CPUs lock or is more efficient and provides the same sequential
consistency. GCC 11 made this switch as well (see
https://gcc.gnu.org/pipermail/gcc-cvs/2020-July/314418.html)
and https://reviews.llvm.org/D61863 and https://reviews.llvm.org/D58632
moved into this direction as well, but didn't touch fence seq_cst.

This switches to `lock or` on all x64 systems, and leaves  `__builtin_ia32_mfence` for folks who
want this precise instruction.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications