From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8671 invoked by alias); 21 Oct 2015 15:56:20 -0000 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 Received: (qmail 8655 invoked by uid 89); 21 Oct 2015 15:56:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 21 Oct 2015 15:56:19 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 0E7CA8E675; Wed, 21 Oct 2015 15:56:18 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-75.phx2.redhat.com [10.3.113.75]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9LFuHmS002561; Wed, 21 Oct 2015 11:56:17 -0400 Subject: Re: [PATCH 1/9] ENABLE_CHECKING refactoring To: Mikhail Maltsev , Bernd Schmidt , gcc-patches mailing list , Richard Biener References: <56130763.4070206@gmail.com> <561D7899.9080401@redhat.com> <5623398D.7040809@gmail.com> <5624D05F.8080203@redhat.com> <5624EED7.2070401@gmail.com> From: Jeff Law Message-ID: <5627B5A1.60609@redhat.com> Date: Wed, 21 Oct 2015 15:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5624EED7.2070401@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg02097.txt.bz2 On 10/19/2015 07:23 AM, Mikhail Maltsev wrote: > On 10/19/2015 02:13 PM, Bernd Schmidt wrote: >> But for normal C conditions the patches end up using flag_checking, so >> the CHECKING_P macro buys us nothing over ENABLE_CHECKING. > Presumably 'if (CHECKING_P)' can be used for performance-critical parts > (in this case the condition will be DCE-d) and also for those parts of > the compiler which we want to decouple from 'options.h'. > IIRC, Jeff's idea was get rid of 'ENABLE_CHECKING' completely and use > either 'flag_checking' or 'CHECKING_P'. But I don't know what is the > consensus on it (I would like to hear Jeff's and Richard's opinion). > Of course it will be easy for me to adjust the patch to whatever the > final decision will be. Bernd, The problem is the existing ENABLE_CHECKING conditions. Anything which is #ifdef ENABLE_CHECKING will have its behavior changed if we change things so that ENABLE_CHECKING is always defined with a value. So if we wanted to continue to use ENABLE_CHECKING, but with a value, then every #ifdef has to be fixed all-at-once. By using CHECKING_P we can incrementally work our way through uses of ENABLE_CHECKING, converting them as we go as we're not changing the meaning of ENABLE_CHECKING. Once everything is converted, we just drop ENABLE_CHECKING completely. Does using CHECKING_P make more churn? Perhaps, but it allows us the freedom to incrementally fix the existing code rather than having to do everything at once. jeff