On 01/10/19 22:05 +0200, François Dumont wrote:
On 9/27/19 1:24 PM, Jonathan Wakely wrote:
On 20/09/19 07:08 +0200, François Dumont wrote:
I already realized that previous patch will be too controversial
to be accepted.
In this new version I just implement a real memmove in __memmove
so
A real memmove doesn't just work backwards, it needs to detect any
overlaps and work forwards *or* backwards, as needed.
ok, good to know, I understand now why using __builtin_memcopy didn't
show any performance enhancement when I tested it !
I think your change will break this case:
#include <algorithm>
constexpr int f(int i, int j, int k)
{
int arr[5] = { 0, 0, i, j, k };
std::move(arr+2, arr+5, arr);
return arr[0] + arr[1] + arr[2];
}
static_assert( f(1, 2, 3) == 6 );
This is valid because std::move only requires that the result iterator
is not in the input range, but it's OK for the two ranges to overlap.
I haven't tested it, but I think with your change the array will end
up containing {3, 2, 3, 2, 3} instead of {1, 2, 3, 2, 3}.
Indeed, I've added a std::move constexpr test in this new proposal
which demonstrate that.
C++ Standard clearly states that [copy|move]_backward is done
backward. So in this new proposal I propose to add a __memcopy used in
copy/move and keep __memmove for *_backward algos. Both are using
__builtin_memmove as before.
Then they *really* need better names now (__memmove was already a bad
name, but now it's terrible). If the difference is that one goes
forwards and one goes backwards, the names should reflect that.
I'll review it properly tomorrow.
