[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #49 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to M Welinder from comment #48)
> It's your (1).  gcc is changing a program that can rely on errno not being
> changed to one where the C library can change it.  (The current C library or
> any future library that the resulting binary may be dynamically linked
> against.)

Ick.  Standards continue to surprise me ;)

> Is there any real-world situation that benefits from introducing these
> calls?  It has the feel of optimizing for a benchmark.

People are good in writing inefficient code and replacing say, an open
coded strlen by an actual call to strlen enables followup transforms
that rely on strlen appearing as strlen and not an open-coded variant
(I realize that technically one might find a way to implement that without
actually emitting a call in the end).

And yes, optimizing (repeated) calls of strlen or replacing open-coded
large memcpy by a library call to optimized functions can make a noticable
difference even for non-benchmarks.

We're currently generating calls to memcpy, memmove, memset and strlen.

We are also replacing memmove with memcpy, printf with puts or putc, all
of those transforms are then invalid because of (1) as well.

We are treating -fno-math-errno as applying to non-math functions and
we don't have any -fno-errno or way of analyzing/annotating whether a
program is interested in the state of errno (not only but mainly because
identifying accesses to errno is non-trivial).

Note this issue (invalid because of (1)) should probably be split out
to a separate bug.