From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20068 invoked by alias); 14 Feb 2011 19:44:59 -0000 Received: (qmail 20060 invoked by uid 22791); 14 Feb 2011 19:44:58 -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 Feb 2011 19:44:53 +0000 Received: (qmail 2566 invoked from network); 14 Feb 2011 19:44:52 -0000 Received: from unknown (HELO ?84.152.194.193?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Feb 2011 19:44:52 -0000 Message-ID: <4D598613.8040808@codesourcery.com> Date: Mon, 14 Feb 2011 19:49:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101211 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Eric Botcazou CC: Jeff Law , gcc-patches@gcc.gnu.org, "H.J. Lu" Subject: Re: [x32] PATCH: PR middle-end/47725: [x32] error: unable to find a register to spill in class DIREG References: <20110214185738.GA13004@intel.com> <4D597E72.8030806@redhat.com> <201102142021.03117.ebotcazou@adacore.com> In-Reply-To: <201102142021.03117.ebotcazou@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 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-02/txt/msg00919.txt.bz2 On 02/14/2011 08:21 PM, Eric Botcazou wrote: >> So all you're doing is trading one performance issue for another. > > If adding a copy to a new pseudo was really a performance issue, we would have > many issues thoughout the compiler. AFAIK it's a classical trick. The insns we're dealing with here can potentially get REG_EQUIV notes attached to them, so they're a bit special. At least it needs to be verified that the optimization in IRA which moves such insns before their only use still triggers (PR42235). I agree with Jeff that combine would be the correct place to fix this. At least it takes class_likely_spilled_p into account, so it will restrict only those machines where extending the lifetime of hard regs is dangerous. Bernd