From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26894 invoked by alias); 7 Feb 2006 00:30:14 -0000 Received: (qmail 26873 invoked by uid 48); 7 Feb 2006 00:30:11 -0000 Date: Tue, 07 Feb 2006 00:30:00 -0000 Message-ID: <20060207003011.26872.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/15792] missed subreg optimization In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ian at airs dot com" 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-02/txt/msg00589.txt.bz2 List-Id: ------- Comment #8 from ian at airs dot com 2006-02-07 00:30 ------- Yes, I still get an unnecessary move in your test case which uses addition. One reason this happens is because the addition can not be split until after the reload pass is complete. That is because the add relies on the condition code registers, but reload can clobber the condition code registers between any arbitrary pair of instructions. Another reason this happens is that the compiler knows how to set the condition flags using a bitwise or, but it does so using a scratch register to hold the destination of the bitwise or. The register allocator is not clever enough to see that if it has a DImode pair of registers which dies in the insn, that it can use the second register in the DImode pair as the scratch register. If the register allocator saw that, then it could use that register as the scratch register and avoid allocating a new scratch register and copying the value into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792