From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21162 invoked by alias); 28 Sep 2005 16:52:23 -0000 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 Received: (qmail 21145 invoked by uid 48); 28 Sep 2005 16:52:18 -0000 Date: Wed, 28 Sep 2005 16:52:00 -0000 Message-ID: <20050928165218.21144.qmail@sourceware.org> From: "hubicka at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050809220454.23302.dann@godzilla.ics.uci.edu> References: <20050809220454.23302.dann@godzilla.ics.uci.edu> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/23302] [4.1 Regression] extra move generated on x86 X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg03514.txt.bz2 List-Id: ------- Additional Comments From hubicka at gcc dot gnu dot org 2005-09-28 16:52 ------- The actual problem here is that from combine's point of view the two alternatives (lea preceeded by loads, or add with memory operand followed by shift) looks equivalent and previously the shorter sequence was purely choosed by luck because combine followed the right edge first. It is not quite possible to solve this by combine's splitting mechanizm as the number of instruction don't change before the read-modify instructions are broken up. While it might be probably possible to design peephole or combiner insn patter I am tempted to close this and PR 23303 as WONTFIX as it seems to me we was optimizing this by pure luck and the patch seems to have overall positive effect on code size... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23302