From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4756 invoked by alias); 14 Mar 2011 17:38:00 -0000 Received: (qmail 4660 invoked by uid 22791); 14 Mar 2011 17:38:00 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Mar 2011 17:37:55 +0000 Received: (qmail 26867 invoked from network); 14 Mar 2011 17:37:53 -0000 Received: from unknown (HELO ?84.152.213.251?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Mar 2011 17:37:53 -0000 Message-ID: <4D7E5267.1080000@codesourcery.com> Date: Mon, 14 Mar 2011 17:38:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Richard Earnshaw CC: Andrew Stubbs , gcc-patches@gcc.gnu.org, patches@linaro.org Subject: Re: [PATCH][ARM] Discourage use of NEON on Cortex-A8 References: <4D7CF174.1090608@codesourcery.com> <1300122644.6014.46.camel@e102346-lin.cambridge.arm.com> In-Reply-To: <1300122644.6014.46.camel@e102346-lin.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00750.txt.bz2 On 03/14/2011 06:10 PM, Richard Earnshaw wrote: > > On Sun, 2011-03-13 at 16:31 +0000, Andrew Stubbs wrote: >> This patch discourages the use of NEON for integer operations on ARM >> Cortex-A8. >> >> The problem is that transferring data from NEON/VFP registers to core >> registers is prohibitively expensive on A8. This should not affect >> Cortex-A9 in the same way. >> >> This change gives a 6% increase in performance on SPEC2000 crafty, on an >> imx51 board. >> >> An older version of the patch has been used for some time in the >> CodeSourcery and Linaro toolchains, so it's fairly well tested. >> >> OK (for stage 1)? >> >> Andrew > > There's no denying numbers like that, so I'm going to approve this for > stage 1, but I'm far from convinced that this isn't papering over other > problems. Oh, I agree. I seem to recall we tried using REGISTER_MOVE_COST, but it didn't help. Ideally, we'd fix this in the register allocator and in lower-subreg, but I believe that would be a significantly larger project. You'd have to detect that if a certain pseudo is allocated to a NEON register, this would cause an expensive register move (because it's used in an insn that only allows GENERAL_REGS), and then recursively every other operation that involves this pseudo also needs to avoid NEON registers for the same reason. Doing this in lower-subreg would give the best results (splitting pseudos that shouldn't go into NEON regs and leaving the others alone), but it would also work to do it in IRA. Bernd