[Bug tree-optimization/50693] Loop optimization restricted by GOTOs

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-11 14:50:51 UTC ---
(In reply to comment #17)
> LLVM appears to be able to recognize memset of any value, not just zero.  And
> apparently performs control flow simplification before attempting to recognize
> the idiom, so it can expose the loop created by the convoluted GOTOs.

Well, GCC also performs lots of control flow simplifications, just the bb's
aren't merged here because that would mean the user label would be lost,
couldn't be used by the user debugging the code at all.

Vectorization restricts the cfg of the loop.  In successfully vectorized loops
it is unlikely user labels would be very helpful to the user, since multiple
iterations of the loop are performed together.

If we want to handle this obfuscated code, either we'd need to make debugging
experience worse for all loops (say at -O3), no matter if they will be
successfully vectorized or not, or lift up the restrictions in the vectorizer,
so that it would accept multiple basic blocks with only fallthru edges in
between and no phis or something similar, or temporarily merge the block and
split it again after vectorization, readding the user labels.