https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100348
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So the compiler, PRE in particular, has found what we typically call a partial
redundancy. What that means is there's a value computed multiple times on one
more more paths. With careful code motion the compiler can restructure the
code such that the expression is never evaluated more than once on a path *and*
it is only evaluated on paths where it was evaluated before.
In this case the expression is the address computation dstp + 48 which would
get computed via case 1 as well as inside the loop. PRE will restructure the
computation so that the redundant expression evaluation is eliminated without
introducing an evaluation on any path where it didn't already exist. That's a
core tenant of the PRE algorithm.
The net is you have two paths to that store. And the somewhat odd code.
However, I believe PRE is behaving per design. It's also worth noting that as
Jim mentioned, the better solution here is to focus more on getting away from
using the generic memcpy implementation in glibc. The upcoming glibc release
has ifunc support and can dynamically select better memcpy implementations
based on hardware capabilities. So for example, if the hardware handles
unaligned loads/stores efficiently or has vector we can and will select a more
performant memory copier.
As for PRE, as I mentioned, it's behavior is per design.
