From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29519 invoked by alias); 23 Apr 2010 08:13:47 -0000 Received: (qmail 29503 invoked by uid 22791); 23 Apr 2010 08:13:45 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (217.140.96.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 08:13:32 +0000 Received: from cam-owa1.Emea.Arm.com (cam-owa1.emea.arm.com [10.1.255.62]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id o3N8DReI017826; Fri, 23 Apr 2010 09:13:27 +0100 (BST) Received: from [10.1.69.84] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Apr 2010 09:13:27 +0100 Subject: Re: ARM ldm/stm peepholes From: Ramana Radhakrishnan Reply-To: ramana.radhakrishnan@arm.com To: Bernd Schmidt Cc: GCC Patches In-Reply-To: <4BCD9301.2060605@codesourcery.com> References: <4BCD9301.2060605@codesourcery.com> Content-Type: text/plain Date: Fri, 23 Apr 2010 08:24:00 -0000 Message-Id: <1272010406.6783.72.camel@e200593-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2010-04/txt/msg01426.txt.bz2 Hi Bernd, On Tue, 2010-04-20 at 13:41 +0200, Bernd Schmidt wrote: > The patch may need more tuning to decide when to use these instructions; > I'll need suggestions as I don't think I have enough information > available to make these decisions. For now, this uses the same > heuristics as previously, but it may trigger in slightly more > situations. I'm open to suggestions. Apologies for the delayed response, been away from my desk this week and will be away for more today. It would be useful to be able to control ldm /stm generation on a per-core basis i.e. on some cores it might be useful to have ldm's and stm's as a size optimization rather than as a performance optimization. For instance the A8 and A9 have a good ldm and stm setup but there might be circumstances where this might not be the right thing to do. An instance of where you don't want to use ldm / stm is this patch suggested here. http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01553.html . Having a hook that acted as a gate for matching this peephole would be useful. Then we could change this hook to work on a per-core basis or put in any heuristics we want to change or tweak later. > I've tested this quite often with arm-none-linux-gnueabi QEMU testsuite > runs. Yesterday, after fixing an aliasing issue, I managed to get a > successful SPEC2000 run on a Cortex-A9 board (with a 4.4-based compiler; > overall performance minimally higher than before); since then I've only > made cleanups and added comments. Once approved, I'll rerun all tests > before committing. Out of curiosity, was the aliasing issue PR42509 on a 4.4 branch ? If so do you have a testcase that necessitates this fix to be backported to the 4.4 branch upstream as well ? cheers Ramana > > > Bernd