https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 8 Dec 2014, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64191 > > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > The tree-vect-stmts.c change is fine of course. As for loops not being DCEd > if > they have only clobbers in them that preclude that, isn't that optimized away > by RTL optimizers anyway? Or perhaps we could do something about in the loop > pipeline, but IMHO changing DCE is too big and too dangerous hammer. No, RTL doesn't know how to DCE loops (it would need to prove the loop is not infinite). GIMPLE DCE is where that happens now. So I'm afraid there isn't any other way of fixing that besides making DCE do it. I'm testing the patch to see if we have anything in the testsuite that regresses. Can you think of something? I can only think of using pointer arithmetic to store to a part of a later destructed object. That would require both addresses to be not dependent on each other, like weird_base_1 = ... base_2 = weird_base_1 + 4B; MEM[weird_base_1, 8B] = 4; *base_2 = CLOBBER; like you may get if using placement new / delete on an offsetted address?
