public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug target/105661] New: Comparisons to atomic variables generates less efficient code @ 2022-05-19 12:59 redbeard0531 at gmail dot com 2022-10-26 23:34 ` [Bug rtl-optimization/105661] " pinskia at gcc dot gnu.org ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: redbeard0531 at gmail dot com @ 2022-05-19 12:59 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105661 Bug ID: 105661 Summary: Comparisons to atomic variables generates less efficient code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: redbeard0531 at gmail dot com Target Milestone: --- With normal variables, gcc will generate a nice cmp/js pair when checking if the high bit is null. When using an atomic, gcc generates a movzx/test/js triple, even though it could use the same codegen as for a non-atomic. https://godbolt.org/z/GorvWfrsh #include <atomic> #include <cstdint> [[gnu::noinline]] void f(); uint8_t plain; std::atomic<uint8_t> atomic; void plain_test() { if (plain & 0x80) f(); } void atomic_test() { if (atomic.load(std::memory_order_relaxed) & 0x80) f(); } With both -O2 and -O3 this generates: plain_test(): cmp BYTE PTR plain[rip], 0 js .L4 ret .L4: jmp f() atomic_test(): movzx eax, BYTE PTR atomic[rip] test al, al js .L7 ret .L7: jmp f() ARM64 seems to be hit even harder, but I don't know that platform well enough to know if the non-atomic codegen is valid there https://godbolt.org/z/c3h8Y1dan. It seems likely though, at least for a relaxed load. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug rtl-optimization/105661] Comparisons to atomic variables generates less efficient code 2022-05-19 12:59 [Bug target/105661] New: Comparisons to atomic variables generates less efficient code redbeard0531 at gmail dot com @ 2022-10-26 23:34 ` pinskia at gcc dot gnu.org 2022-10-26 23:35 ` pinskia at gcc dot gnu.org 2023-02-09 18:11 ` pinskia at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: pinskia at gcc dot gnu.org @ 2022-10-26 23:34 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105661 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |50677 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement Component|target |rtl-optimization Last reconfirmed| |2022-10-26 --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> --- The aarch64 issue is not really a big difference but it is the same issue really. Basically we don't optimize anything related to volatile memory even into the address part. This is basically PR 50677 really. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677 [Bug 50677] volatile forces load into register ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug rtl-optimization/105661] Comparisons to atomic variables generates less efficient code 2022-05-19 12:59 [Bug target/105661] New: Comparisons to atomic variables generates less efficient code redbeard0531 at gmail dot com 2022-10-26 23:34 ` [Bug rtl-optimization/105661] " pinskia at gcc dot gnu.org @ 2022-10-26 23:35 ` pinskia at gcc dot gnu.org 2023-02-09 18:11 ` pinskia at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: pinskia at gcc dot gnu.org @ 2022-10-26 23:35 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105661 --- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #1) > Basically we don't optimize anything related to volatile memory even into > the address part. This is basically PR 50677 really. I should say internally for RTL level we do atomic loads as volatile memory. (insn 5 4 0 (set (reg:QI 83 [ _5 ]) (mem/v:QI (symbol_ref:DI ("atomic") [flags 0x2] <var_decl 0x7fefa628cab0 atomic>) [-1 S1 A8])) "/opt/compiler-explorer/gcc-trunk-20221026/include/c++/13.0.0/bits/atomic_base.h":505:24 -1 (nil)) ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug rtl-optimization/105661] Comparisons to atomic variables generates less efficient code 2022-05-19 12:59 [Bug target/105661] New: Comparisons to atomic variables generates less efficient code redbeard0531 at gmail dot com 2022-10-26 23:34 ` [Bug rtl-optimization/105661] " pinskia at gcc dot gnu.org 2022-10-26 23:35 ` pinskia at gcc dot gnu.org @ 2023-02-09 18:11 ` pinskia at gcc dot gnu.org 2 siblings, 0 replies; 4+ messages in thread From: pinskia at gcc dot gnu.org @ 2023-02-09 18:11 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105661 Bug 105661 depends on bug 50677, which changed state. Bug 50677 Summary: volatile forces load into register https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50677 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-02-09 18:11 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-19 12:59 [Bug target/105661] New: Comparisons to atomic variables generates less efficient code redbeard0531 at gmail dot com 2022-10-26 23:34 ` [Bug rtl-optimization/105661] " pinskia at gcc dot gnu.org 2022-10-26 23:35 ` pinskia at gcc dot gnu.org 2023-02-09 18:11 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).