[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 18 Aug 2014, glisse at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
> 
> --- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #1)
> > What kind of std::string code is this?  That is, can we expect
> > memcmp and memcpy to be adjacent (without intermediate memory operations?)
> 
> I don't remember the exact code, but it was similar to:
> std::string("foo")=="bar"
> which, with _GLIBCXX_EXTERN_TEMPLATE=0 (or LTO) gives:
> 
>   _29 = _50 + 24;
>   __builtin_memcpy (_29, "foo", 3);
>   if (_50 != &_S_empty_rep_storage)
>     goto <bb 3>;
> 
>   <bb 3>:
>   MEM[(struct _Rep *)_50].D.20711._M_length = 3;
>   MEM[(char_type &)_50 + 27] = 0;
>   __r_86 = __builtin_memcmp (_29, "bar", 3);
> 
> So it is setting the null character right after the string (could have used
> memcpy of size 4?) and the length right before, which requires tight alias
> checking to be sure that memcmp is not affected :-(
> 
> Probably a bit too specific to be worth it.

Eventually worth "fixing" the libstdc++ side to generate better
initial code?

Other than that it seems this would need careful special-handling
in value-numbering ... not sure if optimizing std::string("foo") == "bar"
is important.