[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72795 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener --- "memory" only includes memory that can be indirectly accessed (thus may be address-taken in this or another CU). You have to add other vars explicitely. Note that we asume that asm volatile might read 'x' through such a pointer.
[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72795
--- Comment #3 from Peter Cordes ---
Based on further discussion
(http://chat.stackoverflow.com/rooms/119045/discussion-between-a3f-and-peter-cordes),
the only bug (or feature?) here is that asm("":::"memory") doesn't count as a
reference for `y`.
i.e. the reason that asm statement works as a barrier is that it might read
`y`, but gcc will still optimize away `y` completely if the only explicit
reference in the translation unit are the stores in g(). This leads to a link
error for:
static int y;
int g() {
y = 1; asm volatile("movl $5, y(%%rip)":::"memory");
y = 2; return y;
}
// int gety(){ return y; } // link error with this commented out, otherwise ok
This can be seen as a feature: It's probably not desirable for any "memory"
clobber to prevent optimizing away any static variables.
If y does exist in the asm output at all, I think gcc's behaviour as far as
making the y=1 and y=2 stores happen separately is correct. If y exists at
all, its value in memory has to be up-to-date.
[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72795 --- Comment #2 from Ahmad Fatoum --- The write that can't be optimized away is the final assignment to x. The `movl$1, x(%rip)` prior to the barrier should've been optimized out, IMO.
[Bug middle-end/72795] Missed optimization of external-linkage variables in presence of barriers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72795
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #1 from Peter Cordes ---
This is not a bug. Adding int gety(){ return y; } to the compilation unit
leads to the same asm for f() and g(). (https://godbolt.org/g/4z94YZ). It can
only be optimized away when there are no observers.
f() and g() have side-effects on global / static variables which of course
can't be optimized away.
BTW, this came up based on http://stackoverflow.com/a/38741832/224132.
