On Fri, Jan 23, 2015 at 10:48:50PM +0100, Jakub Jelinek wrote: > On Fri, Jan 23, 2015 at 03:39:40PM -0600, Segher Boessenkool wrote: > > I understand that argument. But it is not what GCC actually does, nor > > what I think it should do. Consider this program: > > > > --- 8< --- > > int main(void) > > { > > int x[100], y[100]; > > > > x[31] = 42; > > > > asm("# eww %0" : "=m"(y[4]) : : "memory"); > > > > return 0; > > } > > --- 8< --- > > Here x isn't addressable, so it is certainly fine to DSE it. > x shouldn't be considered memory. > If the address of x escaped, either to the assembly or to some global var > etc., then it probably shouldn't be removed.
But GCC does consider it memory. If you look at the (tree) dump files you see both arrays are clobbered after the asm. Tree DCE removes the store to x[31] nevertheless. If the address of x escapes then of course the store to x[31] should not be removed, irrespective of whether the clobber implies a read or not. > > Here is another program: > > > > --- 8< --- > > int main(void) > > { > > int x; > > > > asm("# eww %0" : "=r"(x) : : "memory"); > > asm("# eww %0" : "=r"(x) : : "memory"); > > > > return x; > > } > > --- 8< --- > > > > If "memory" would imply a write and a read, the identical asm here could > > not be CSEd. But it is. > > Certainly not in GCC 4.9 nor trunk. I've committed the patch because it > makes GCC more aggressive again, just not for the "memory" case. Yes, sorry, it is not actually removed by the CSE pass, but much much earlier ("deleted 2 trivially dead insns" in the early RTL "jump" pass). My point is that much of the compiler does not agree that "memory" implies a read. But, to show RTL CSE removes the redundant insn here with older compilers: --- 8< --- int main(void) { int x1, x2; asm("# eww %0" : "=r"(x1) : : "memory"); asm("# eww %0" : "=r"(x2) : : "memory"); return x1 + x2; } --- 8< --- You can argue CSE should not do that. But other passes feel free to remove one of the asms (in the previous program), and they should not either if "memory" implies a read and a write. > In case of two idential non-volatile asms with "memory" clobber, > if there are no intervening memory reads or writes, we can talk about > allowing that to be CSEd despite "memory" being considered unspecified > read and write. If there are stores in between, we certainly should not CSE. If there is a store inbetween, we cannot remove the later asm, which is what CSE would do AFAIK. But we can remove the *earlier* asm (and, in fact, GCC does do that). Segher