From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 8E2253959C32 for ; Tue, 4 May 2021 16:25:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8E2253959C32 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 23F35D6E; Tue, 4 May 2021 09:25:54 -0700 (PDT) Received: from [10.57.61.192] (unknown [10.57.61.192]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 797513F718; Tue, 4 May 2021 09:25:53 -0700 (PDT) Subject: Re: [PATCH] Remove CC0 To: Eric Botcazou Cc: Segher Boessenkool , gcc-patches@gcc.gnu.org References: <952b5c888a98df98249088d81e954d64fad88827.1620082370.git.segher@kernel.crashing.org> <5e1b1ef9-dd0a-7dbe-458d-1df925bcecd1@foss.arm.com> <2091450.NgBsaNRSFp@fomalhaut> From: Richard Earnshaw Message-ID: Date: Tue, 4 May 2021 17:24:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <2091450.NgBsaNRSFp@fomalhaut> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3491.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 16:25:55 -0000 On 04/05/2021 17:22, Eric Botcazou wrote: >> A quick look through the code suggests it's being used for thumb1 code >> gen to try to reproduce the traditional CC0 type behaviour of >> eliminating redundant compare operations when you have sequences such as >> >> cmp a, b >> b d1 >> cmp a, b >> b d2 >> >> The second compare operation can be eliminated. >> >> It might be possible to eliminate this another way by reworking the >> thumb1 codegen to expose the condition codes after register allocation >> has completed (much like x86 does these days), but that would be quite a >> lot of work right now. I don't know if such splitting would directly >> lead to the ability to remove the redundant compares - it might need a >> new pass to spot them. > > Do you mean in addition to the existing pass_compare_elim_after_reload? > No, sounds like that would do the job. :) R.