From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12819 invoked by alias); 31 Mar 2011 21:16:41 -0000 Received: (qmail 12807 invoked by uid 22791); 31 Mar 2011 21:16:39 -0000 X-SWARE-Spam-Status: No, hits=-1.6 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; Thu, 31 Mar 2011 21:16:35 +0000 Received: (qmail 22928 invoked from network); 31 Mar 2011 21:16:35 -0000 Received: from unknown (HELO ?192.168.1.66?) (vries@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Mar 2011 21:16:35 -0000 Message-ID: <4D94EF30.8050308@codesourcery.com> Date: Thu, 31 Mar 2011 21:25:00 -0000 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Jeff Law CC: gcc-patches@gcc.gnu.org, ebotcazou@libertysurf.fr Subject: Re: [PATCH, PR43920, 6/9] Cross-jumping - Use reg-notes. References: <4D94C603.7080505@codesourcery.com> <4D94C88B.4020206@codesourcery.com> <4D94CB00.7080807@codesourcery.com> <4D94CD5F.90900@redhat.com> In-Reply-To: <4D94CD5F.90900@redhat.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-03/txt/msg02288.txt.bz2 On 03/31/2011 08:52 PM, Jeff Law wrote: > On 03/31/11 12:42, Tom de Vries wrote: >> Uses regnotes to analyze whether we can replace insn a by insn b, even >> if we cannot replace insn b by insn a. Uses this info in crossjumping. > Shouldn't this be using single_set rather than digging through PATTERN, > then verifying both are SETs, etc.? > > Otherwise don't you miss most of the benefit on architectures where most > insns clobber the flags register in a PARALLEL with the SET? I see what you mean about missing these insns currently. I guess I will have to check that the non-SET part of the PARALLEL is identical between the 2 insns. I'll update the patch to handle this case. Thanks, - Tom