public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/108712] New: Missing optimization with memory-barrier
@ 2023-02-08 8:33 klaus.doldinger64 at googlemail dot com
2023-02-08 8:43 ` [Bug middle-end/108712] " klaus.doldinger64 at googlemail dot com
2023-02-08 19:41 ` pinskia at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: klaus.doldinger64 at googlemail dot com @ 2023-02-08 8:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108712
Bug ID: 108712
Summary: Missing optimization with memory-barrier
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: klaus.doldinger64 at googlemail dot com
Target Milestone: ---
In the following example the increments of `g` could be optimized to a `g+=20`
equivalent.
But avr-gcc hoists the load of `g` outside the loop but the stores remain
inside the loop.
That produces unneccessary overhead.
(I know that the idionatic solution would be to volatile-qualify the variable
`flag`
make a volatile-access like std::experimental::volatile_load()` or
`ACCESS_ONCE()` (linux kernel).
https://godbolt.org/z/1b6xG5YP4
----
#include <stdint.h>
#include <util/atomic.h>
//#include <signal.h> // do not include that stub: wrong sig_atomic_t
typedef signed char sig_atomic_t; // __SIG_ATOMIC_TYPE__
#include <avr/interrupt.h>
static sig_atomic_t flag;
static uint8_t g;
void func(void) {
for(uint8_t i = 0; i < 20; i++) {
__asm__ __volatile__ ("" : "+m" (flag));
++g;
if (flag) {
flag = 0;
}
__asm__ __volatile__ ("" : "+m" (flag));
}
}
ISR(USART_RXC_vect) {
__asm__ __volatile__ ("" : "+m" (flag));
flag = 1;
}
----
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/108712] Missing optimization with memory-barrier
2023-02-08 8:33 [Bug c/108712] New: Missing optimization with memory-barrier klaus.doldinger64 at googlemail dot com
@ 2023-02-08 8:43 ` klaus.doldinger64 at googlemail dot com
2023-02-08 19:41 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: klaus.doldinger64 at googlemail dot com @ 2023-02-08 8:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108712
--- Comment #1 from Wilhelm M <klaus.doldinger64 at googlemail dot com> ---
And using
__asm__ __volatile__ ("" : : : "memory");
there is no optimization at all.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/108712] Missing optimization with memory-barrier
2023-02-08 8:33 [Bug c/108712] New: Missing optimization with memory-barrier klaus.doldinger64 at googlemail dot com
2023-02-08 8:43 ` [Bug middle-end/108712] " klaus.doldinger64 at googlemail dot com
@ 2023-02-08 19:41 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-08 19:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108712
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |inline-asm,
| |missed-optimization
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The inline-asm is causing GCC not to optimize the code.
Doing the following on x86_64 allows GCC to optimize the g load/stores out of
the loop:
static volatile int flag;
static int g;
void func(void) {
for(int i = 0; i < 20; i++) {
++g;
if (flag) {
flag = 0;
}
}
}
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-02-08 19:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-08 8:33 [Bug c/108712] New: Missing optimization with memory-barrier klaus.doldinger64 at googlemail dot com
2023-02-08 8:43 ` [Bug middle-end/108712] " klaus.doldinger64 at googlemail dot com
2023-02-08 19:41 ` 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).