From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7129 invoked by alias); 14 Jul 2010 18:54:56 -0000 Received: (qmail 7113 invoked by uid 22791); 14 Jul 2010 18:54:56 -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 18:54:50 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6EIsfUs004982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jul 2010 14:54:42 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6EIsfBN027447; Wed, 14 Jul 2010 14:54:41 -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 o6EIsdkL022454; Wed, 14 Jul 2010 14:54:40 -0400 Message-ID: <4C3E07EF.1030306@redhat.com> Date: Wed, 14 Jul 2010 18:54: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> In-Reply-To: <4C3D9C06.60901@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/msg01183.txt.bz2 On 07/14/10 05:14, Bernd Schmidt wrote: > When moving arguments into pseudos, we are being very careful not to > emit any instructions that could possibly clobber other argument > registers. Currently, we generate unnecessarily complicated sequences > of code for simple zero or sign extensions. > > With this patch, we check can_extend_p and the necessary predicates to > see if an extend insn is available for the conversion we have to do. Right, but what guarantee do we have that the conversion insn doesn't clobber a function argument register? ISTM that to be safe you actually have to scan the insns created by gen_extend_insn to ensure they don't clobber something important. I'm not an expert on what ports do these days, but I did work on a port (mn10200) where conversion "insns" where implemented as special function calls under the hood. I don't recall if we allowed those special function calls to have visible side effects, but if they did, they'd show up as clobbers/uses attached to the normal conversion insn. Of course the mn102 is dead, but I think it's method for implementing conversions was valid and if another port were to do something similar it would likely not interact well with your change. > If > so, we emit the insn directly, and create a REG_EQUIV note of the form > (sign_extend (mem)). Creating more REG_EQUIVs seems like a good idea to me. > Reload can't really do anything with these yet, > but there's an optimization in the register allocator to move argument > loads directly before their use if there's only one use. On Thumb-2 > this happens already, we seem to generate better code than before. > Unfortunately Thumb-1, which the PR is about, has some other problems > which I'll try to fix later. > 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. Jeff