From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7602 invoked by alias); 18 Mar 2009 10:11:57 -0000 Received: (qmail 7502 invoked by uid 48); 18 Mar 2009 10:11:38 -0000 Date: Wed, 18 Mar 2009 10:11:00 -0000 Message-ID: <20090318101138.7501.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/39480] generated memcpy causes trouble in assignment In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-03/txt/msg01287.txt.bz2 ------- Comment #24 from jakub at gcc dot gnu dot org 2009-03-18 10:11 ------- The problem with that is that in most cases you won't be able to prove it and memmove is certainly more expensive than memcpy and usually isn't even expanded inline (unless it is optimized into memcpy by proving non-overlap). fold_builtin_memory_op currently optimizes memmove into memcpy only when source is read-only or length is 1 byte, could be improved by analysis of non-overlapping, but in many cases you really don't know if the two pointers can or can't overlap. Having an internal builtin for the case that either source and dest don't overlap, or are equal could improve things, then when expanding that inline if we knew the expanded code is ok for src == dst, we could expand it as inline memcpy and if we didn't know that, we could add (predicted unlikely) jump around the memcpy call (or inline expansion that is not safe for src == dst). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480