From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E44BE3858C42; Tue, 23 Apr 2024 12:08:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E44BE3858C42 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1713874123; bh=mIDXcTT9+heZKhmZnjFc8dHTSEL9m/pPqoxpGMTYJ6g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=c1djFWVrhEwLx3eK98DBZgrfmkanHKw0t01IZ8xjG6QIhCGvXAoTBRx3O/8/lF/E5 4netueWoNdOLRK7j0iJcOIH2g+n0BJncyrf+6fFsp97NatkPaNaXqy2xGScZE0HB/5 rACovT2GgX25cpR+KEw2g4ucOPtlv8YcLIgKCDxM= From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible Date: Tue, 23 Apr 2024 12:08:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114821 --- Comment #6 from Jan Hubicka --- Thanks. I though the relocate_a only cares about the fact if the pointed-to type can be bitwise copied. It would be nice to early produce memcpy from libstdc++ for std::pair, so the second patch makes sense to me (I did not t= est if it works) I think it would be still nice to tell GCC that the copy loop never gets overlapping memory locations so the cases which are not early optimized to memcpy can still be optimized later (or vectorized if it does really someth= ing non-trivial). So i tried your second patch fixed so it compiles: diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h b/libstdc++-v3/include/bits/stl_uninitialized.h index 7f84da31578..0d2e588ae5e 100644 --- a/libstdc++-v3/include/bits/stl_uninitialized.h +++ b/libstdc++-v3/include/bits/stl_uninitialized.h @@ -1109,8 +1109,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION template _GLIBCXX20_CONSTEXPR inline __enable_if_t::value, _Tp*> - __relocate_a_1(_Tp* __first, _Tp* __last, - _Tp* __result, + __relocate_a_1(_Tp* __restrict __first, _Tp* __last, + _Tp* __restrict __result, [[__maybe_unused__]] allocator<_Up>& __alloc) noexcept { ptrdiff_t __count =3D __last - __first; @@ -1147,6 +1147,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION std::__niter_base(__result), __alloc); } + template + _GLIBCXX20_CONSTEXPR + inline _Tp* + __relocate_a(_Tp* __restrict __first, _Tp* __last, + _Tp* __restrict __result, + allocator<_Up>& __alloc) + noexcept(std::__is_bitwise_relocatable<_Tp>::value) + { + return std::__relocate_a_1(__first, __last, __result, __alloc); + } + /// @endcond #endif // C++11 it does not make ldist to hit, so the restrict info is still lost. I think= the problem is that if you call relocate_object the restrict reduces scope, so = we only know that the elements are pairwise disjoint, not that the vectors are. This is because restrict is interpreted early pre-inlining, but it is really Richard's area. It seems that the patch makes us to go through __uninitialized_copy_a inste= ad of __uninit_copy. I am not even sure how these are different, so I need to stare at the code bit more to make sense of it :)=