From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24063 invoked by alias); 25 Sep 2006 17:03:34 -0000 Received: (qmail 24027 invoked by uid 48); 25 Sep 2006 17:03:26 -0000 Date: Mon, 25 Sep 2006 17:03:00 -0000 Message-ID: <20060925170326.24026.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/29215] [4.0/4.1/4.2 Regression] memcpy is not fully optimized any more In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pinskia at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-09/txt/msg02355.txt.bz2 List-Id: ------- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-25 17:03 ------- (In reply to comment #8) > I think the real problem is in this example a is written to the stack and not > optimised away. For the original test case the lazy stack cleanup would explain > the multiple assignments. You are partly correct. What is happening is that we don't optimize memcpy at the tree level. So we expand to have a always in a stack slot and then we optimize the memcpy at the rtl level (by inlining it) and the later passes are there to do constant prop but we don't rememove the store to a even though it is dead. 3.4.0 and before used to do this via the addressof rtl which fixed the problem by not committing a into the stack until later. -- pinskia at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |missed-optimization Known to fail| |4.0.0 4.1.0 4.2.0 Known to work| |3.4.0 Summary|Unnecessary use of stack |[4.0/4.1/4.2 Regression] |space |memcpy is not fully | |optimized any more Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215