http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
--- Comment #24 from Marc Glisse <glisse at gcc dot gnu.org> --- Thank you. Sadly, for the example in comment #15, this is not quite enough, I need to add forwprop+ccp right before the VRP1 pass (and then the range check is eliminated, the vectorizer works and perfs are the same as without range checking). Indeed, we learn that size is (start+4000000)-start quite late (need to inline, look through mem_refs, etc -> FRE2) so the previous forwprop pass is too early. VRP2 is too late if we hope to vectorize, and in any case it fails to remove the range checks, because it is confused by the new shape of the loops (possibly related to PR 25643, or not). The VRP2 failure looks funny with these consecutive lines: # ivtmp.80_92 = PHI <ivtmp.80_53(9), ivtmp.80_83(8)> # RANGE [10101, 989898] NONZERO 0x000000000000fffff _23 = ivtmp.80_92; if (ivtmp.80_92 > 999999) Really, we don't know that the comparison returns false? For the overflow in sizeof(*p) * sz, would it make sense to have the front-end generate, when it sees p+sz: if((long)sz>LONG_MAX/sizeof(*p)) __builtin_unreachable() (or abort or a sanitizer call depending on options), and a similar check for large negative values? It feels very heavy for such a common operation, but if the FE is the only one with the information, I am not sure how else to pass it down to gimple. I might file a low priority enhancement PR about extending reassoc to pointers, that would still cover some cases (and it wouldn't make the forwprop transformation useless because of single-use restrictions).
