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.