From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10658 invoked by alias); 9 Apr 2010 16:44:58 -0000 Received: (qmail 10645 invoked by uid 22791); 9 Apr 2010 16:44:56 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Apr 2010 16:44:52 +0000 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1O0HK6-0000pk-HT for gcc@gcc.gnu.org; Fri, 09 Apr 2010 12:44:50 -0400 Received: (qmail 14901 invoked from network); 9 Apr 2010 16:44:46 -0000 Received: from unknown (HELO ?192.168.2.100?) (wilson@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Apr 2010 16:44:46 -0000 Message-ID: <4BBF597D.4000501@codesourcery.com> Date: Fri, 09 Apr 2010 16:52:00 -0000 From: Jim Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: roy rosen CC: gcc@gcc.gnu.org Subject: Re: lower subreg optimization References: <4BBB6358.4050602@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00173.txt.bz2 On 04/07/2010 10:48 PM, roy rosen wrote: > I saw in arm/neon.md that they have a similar problem: > ... > Their solution is also not complete. > What is the proper way to handle such a case and how do I let gcc know > that this is a simple move instruction so that gcc would be able to > optimize it out? The only simple solution at the moment is the one that the ARM port is using. You avoid emitting the move when you got the lucky reg-alloc result, and you emit the move when you aren't lucky. As the neon.md comment suggests, and as Ian Taylor mentioned in his response, a possible solution is to modify the lower-subreg.c pass somehow so that it no longer splits subregs of vector modes, possibly controlled by a hook. We might be able to modify the register allocator to look for this pattern, to increase the chances of getting the good reg-alloc result, but the lower-subreg.c change is probably better. Another solution might be to add a pass (or modify an existing one like regmove.c) to try to put things back together again, but this is probably also not as good as the lower-subreg.c change. Jim