From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12753 invoked by alias); 14 Jul 2010 22:22:08 -0000 Received: (qmail 12744 invoked by uid 22791); 14 Jul 2010 22:22:07 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Jul 2010 22:22:01 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6EMLqdB000862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jul 2010 18:21:52 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6EMLpXD007580; Wed, 14 Jul 2010 18:21:51 -0400 Received: from [172.17.76.3] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o6EMLo13012359; Wed, 14 Jul 2010 18:21:50 -0400 Message-ID: <4C3E387E.2080202@redhat.com> Date: Wed, 14 Jul 2010 22:22:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: Bernd Schmidt CC: GCC Patches Subject: Re: Emit more REG_EQUIV notes for function args (PR42235) References: <4C3D9C06.60901@codesourcery.com> <4C3E07EF.1030306@redhat.com> <4C3E3078.7020706@codesourcery.com> In-Reply-To: <4C3E3078.7020706@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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-07/txt/msg01203.txt.bz2 On 07/14/10 15:47, Bernd Schmidt wrote: > On 07/14/2010 08:54 PM, Jeff Law wrote: > >> In theory, given the REG_EQUIV note we ought to get an entry in >> reg_equiv_mem, which the code I'm working on knows it can use instead of >> shoving the pseudo into a stack slot. Effectively, my code will >> rematerialize the argument from the equivalent memory location >> regardless of the number of uses. >> > Reload can do that already, I think, but it's not prepared to handle a > (zero_extend (mem)) inside a REG_EQUIV note. That should be reasonably > trivial to add if the reg is never set other than in the initializing insn. > reload does, but it's code that can be problematical. For example, replacement of an unallocated pseudo with its equivalent can trigger secondary reloads, spills, etc. My code creates a new pseudo/allocno for the various ranges where the unallocated pseudo is live then asks IRA to color those split-range pseudos/allocnos. What we end up presenting to reload is cleaner; though often they result in the same final code. Handling this case falls out nicely from the infrastructure for splitting ranges of unallocated pseudos without equivalent forms (it's probably a couple dozen lines of new code). jeff