This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Efficiency of memmove vs. generic typed copy


Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Our typed std::copy() is specialized for T*, where T is a POd, as a
> forwarding function to generic memmove() from the C library. 
> Do we have evidence that for the majority of the targets supported by
> GCC, that is a win compared to the typed generic copy()
> implementation that exposes alignment and other goodies to the optimizer?
> On which targets do we know copy() wins?

Note that gcc will recognize a call to memmove, and handle it
specially (unless you use -fno-builtin).

That said, the special handling is not all that clever, and could be
improved.  For example, it could try to use alias analysis to prove
that the buffers can not overlap, and call memcpy in that case (the
special handling of memcpy is fairly clever).  And where the size is
constant and small, it would sometimes make sense to load it all and
then store it all.  And at high optimization levels, if the special
handling of memcpy will do something clever, it would make sense to
compare the pointers at runtime and call the appropriate form of
memcpy (move_by_pieces should be able to support a general reverse
move, perhaps with a little tweaking).

The code is expand_builtin_memmove and fold_builtin_memmove in
builtins.c.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]