https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 19 Aug 2014, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156 > > --- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #4) > > Eventually worth "fixing" the libstdc++ side to generate better > > initial code? > > Replacing memcpy(,,3)+assign(,'\0') with memcpy(,,4) can indeed be done at the > libstdc++ level (although simplify_builtin_call in tree-ssa-forwprop.c already > does a transformation extremely similar and could be extended). As shown in > comment #3, the test/jump will disappear when we move to C++11. > > But essentially, it can't avoid doing memcpy, setting the length of the > string, > and calling memcmp. > > One surprising thing it does not is, at the beginning of operator==, check if > the sizes are the same before calling memcmp... > > > Other than that it seems this would need careful special-handling > > in value-numbering ... > > That seems like the best place indeed. > > > not sure if optimizing std::string("foo") == "bar" is important. > > The question is how many other optimizations this would enable. I remember > other cases where we couldn't see through memcpy well enough (PR 58483 for > instance, there were others probably more relevant), but I don't know if this > would help them. > > In any case, I agree this isn't a priority. The special thing with memcmp is that it evaluates to a value we'd like to compute while the usual look-through-memcpy is for value-numbering loads. So it won't be that easy... IMHO it would be nicer if we'd fix PR52171 which should be able to catch your simple case then via existing value-numbering code at least if the compare includes the trailing zero.
