diff options
| author | Valentin Churavy <v.churavy@gmail.com> | 2025-03-11 16:12:23 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-03-11 16:12:23 +0100 |
| commit | b334321678d4df2d8b1572301c827cae4d4097e2 (patch) | |
| tree | 7dfa5bf405edf10fce94f2fc3feb9e210cd8adcf /clang/lib/Frontend/CompilerInvocation.cpp | |
| parent | 222b99d3aac577a561592f160b9ac39f8740d3e5 (diff) | |
| download | llvm-b334321678d4df2d8b1572301c827cae4d4097e2.zip llvm-b334321678d4df2d8b1572301c827cae4d4097e2.tar.gz llvm-b334321678d4df2d8b1572301c827cae4d4097e2.tar.bz2 | |
[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.
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions