From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 0DC373858D35; Tue, 21 Nov 2023 18:11:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0DC373858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=inria.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0DC373858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.134.164.104 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700590270; cv=none; b=Fi5pOMjmUlqGhS7PXpp9Co/IrO755W+/M7SzliHKALKxeuVufx3tMIRCgvINMrCSvE8Kfqt4IXsWyxO1RzunP8P/FQQuvsTnVeMZF+N08wXmd4DO3gIEp1u/LkRPjx6+Ge6c3blO+jpVF+3OQElCsGJ/RvIldrwYdgqwZAo7290= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700590270; c=relaxed/simple; bh=slpPK7HLeDjjSy2Nz3IxZA6azoPdC+QFCXJSf5soJfQ=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=Gm/5Ow1KMkEeL3Otzs8XL7ewiQwkzURypq5RKrB6kXy6dhbVBto1R3x+q/i2FUSns5MD1sW/MrzpOWbqTIcx0rKv5J4tgNx3rD9slDYwkwZFt88CwkBXP3ONevvmYHT+TdNNzXPfPi5ZjA2NoKK97/TfgFSthV+eF0fqNP5oRNA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=5kShM8DTYSnJYN2ktVe7cLRG8XfE6FMxOeS5GL5BT74=; b=ebXteqJNaHYUCiXUN/Jx8NjQky1ZBM4aPss2aIKcGYrWBPRnkTccX+vR WiTZLNk2eJS4xGHwIZo/n+0Pzu/1ZpXupdtVgmV4UqZpo2nhbjFBZnfkm NQNcuSczzvz5mUf9/2au7mObeksyyZXdzOTvjNYrWKVKeX2+2i3VdtXJW 0=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=marc.glisse@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.04,216,1695679200"; d="scan'208";a="72169183" Received: from 71.79.12.109.rev.sfr.net (HELO hippo) ([109.12.79.71]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Nov 2023 19:11:06 +0100 Date: Tue, 21 Nov 2023 19:11:04 +0100 (CET) From: Marc Glisse To: Jonathan Wakely cc: Jan Hubicka , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: libstdc++: Turn memmove to memcpy in vector reallocations In-Reply-To: Message-ID: <5a92f6c6-56ba-8f0e-8db8-9bce18b2779e@inria.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 21 Nov 2023, Jonathan Wakely wrote: > CC Marc Glisse who added the relocation support. He might recall why > we use memmove when all uses are for newly-allocated storage, which > cannot overlap the existing storage. Going back a bit: https://gcc.gnu.org/pipermail/gcc-patches/2019-April/520658.html "I think the call to memmove in __relocate_a_1 could probably be memcpy (I don't remember why I chose memmove)" Going back a bit further: https://gcc.gnu.org/pipermail/gcc-patches/2018-September/505800.html "I had to add a special case for trivial types, using memmove, to avoid perf regressions, since relocation takes precedence over the old path that is specialized to call memmove." So the reason seems to be because vector already used memmove before my patch. You can dig further if you want to check why that is ;-) -- Marc Glisse