[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-12-10 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|---

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-07-24 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #16 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:8c7bb540803e8bff9998bc86806e8a83acc75370 commit r11-2306-g8c7bb540803e8bff9998bc86806e8a83acc75370 Author: Uros Bizjak Date: Fri J

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-07-23 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #15 from Uroš Bizjak --- (In reply to Joseph C. Sible from comment #14) > I notice this change affects -Os too, even though "lock orq $0,(%rsp)" is 6 > bytes and "mfence" is only 3 bytes. Yes, we can emit mfence for -Os. I'm testing

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-07-23 Thread josephcsible at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 Joseph C. Sible changed: What|Removed |Added CC||josephcsible at gmail dot com --- Comm

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-07-21 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #13 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:02363d5fdb862a11e6e65ac5b0d1f5ee0c422dc3 commit r11-2255-g02363d5fdb862a11e6e65ac5b0d1f5ee0c422dc3 Author: Uros Bizjak Date: Tue J

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-07-20 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #12 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:3c5e83d5b32c31b11cf1684bf5d1ab3e7174685c commit r11-2232-g3c5e83d5b32c31b11cf1684bf5d1ab3e7174685c Author: Uros Bizjak Date: Mon J

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-07-20 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 Uroš Bizjak changed: What|Removed |Added Attachment #48756|0 |1 is obsolete|

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-19 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #10 from Uroš Bizjak --- Created attachment 48756 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48756&action=edit Proposed patch Patch in testing, survives GOMP testcases. On a related note, the patch uses TARGET_USE_XCHG_FOR

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-19 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #9 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #8) > The culprit is the %esp here, that adds the 0x67 prefix to the insn and > will only work if %rsp is below 4GB. Ah, indeed... I was in a bit of hurry and didn't no

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-19 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-19 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #7 from Uroš Bizjak --- Actually, x86_64 (at least my Fedora 32) does not like operations on stack: Starting program: /sdd/uros/git/gcc/gcc/testsuite/gcc.dg/atomic/a.out Program received signal SIGSEGV, Segmentation fault. 0x00

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-18 Thread andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #6 from andysem at mail dot ru --- Also, I think (%%rsp) can be rather far from the top of the stack if the stack frame is large. This may mean it's less likely to be in data cache. Having a dummy variable ensures that it is close to t

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-18 Thread andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #5 from andysem at mail dot ru --- > Please also read [1] why we avoid -4(%%esp). I believe, memcheck would complain because the value at -4(%%rsp) would be uninitialized. This is unfortunate. The workaround could be to initialize it

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-18 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #4 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #3) > How about the following patch: Surely, mfence_nosse needs to be enabled also for TARGET_USE_XCHG_FOR_ATOMIC_STORE. > This will generate "lock orl $0, (%rsp)" instea

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-18 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #3 from Uroš Bizjak --- How about the following patch: --cut here-- diff --git a/gcc/config/i386/sync.md b/gcc/config/i386/sync.md index 9ab5456b227..7d9442d45b7 100644 --- a/gcc/config/i386/sync.md +++ b/gcc/config/i386/sync.md @@ -

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-18 Thread andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 --- Comment #2 from andysem at mail dot ru --- gcc 10.1 only optimizes __atomic_store_n(seq_cst) to xchg, but not the fence. Also, consider applying the same optimization to __sync_synchronize().

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

2020-06-18 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750 Andrew Pinski changed: What|Removed |Added Depends on||91719 --- Comment #1 from Andrew Pinski