[Bug tree-optimization/81330] missing strlen optimization with intervening memcpy

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81330

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 5 Jul 2017, msebor at gcc dot gnu.org wrote:

> GCC eliminates redundant calls to strlen() with intervening calls to strcpy but
> it misses an opportunity to do the same when the intervening call is to memcpy
> instead.  In the test case below, since both strcpy and memcpy require that the
> copies do not overlap, it's safe to assume that neither call modifies any part
> of the source string, including the terminating nul, and so the second strlen
> call can be replaced with the result of the first in both functions, not just
> in f().  The strlen dump shows that GCC doesn't take advantage of this
> guarantee in the memcpy case.
> 
> (The second strlen call in g is replaced with the result of the first in g when
> memcpy is passed n0 + 1 as the size but I don't see why that should make a
> difference.)

I don't see the basis for the optimization with memcpy being safe without 
n0 + 1 as size.  If the size is n0, it's perfectly legitimate for d to 
point to the terminating NUL, as in that case the memcpy arguments are 
adjacent but nonoverlapping blocks of n0 bytes in memory.