From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100475 invoked by alias); 6 Nov 2015 07:12:54 -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 100461 invoked by uid 89); 6 Nov 2015 07:12:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Fri, 06 Nov 2015 07:12:53 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 07B9FC003313; Fri, 6 Nov 2015 07:12:51 +0000 (UTC) Received: from localhost (ovpn-116-72.ams2.redhat.com [10.36.116.72]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA67CnG5025353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Nov 2015 02:12:50 -0500 Received: by localhost (Postfix, from userid 1001) id 854961A04B0; Fri, 6 Nov 2015 08:12:48 +0100 (CET) From: Dodji Seketeli To: David Malcolm Cc: Jeff Law , gcc-patches@gcc.gnu.org, Richard Biener Subject: Re: Status of rich location work (was Re: [PATCH 06/10] Track expression ranges in C frontend) References: <1442957171-22904-1-git-send-email-dmalcolm@redhat.com> <1445632918-29617-1-git-send-email-dmalcolm@redhat.com> <1445632918-29617-7-git-send-email-dmalcolm@redhat.com> <56330AEF.7080202@redhat.com> <1446491668.2994.84.camel@surprise> X-URL: http://www.redhat.com Date: Fri, 06 Nov 2015 07:12:00 -0000 In-Reply-To: <1446491668.2994.84.camel@surprise> (David Malcolm's message of "Mon, 02 Nov 2015 14:14:28 -0500") Message-ID: <86oaf7zjm7.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2015-11/txt/msg00558.txt.bz2 > Talking about risks: the reduction of the space for ordinary maps by a > factor of 32, by taking up 5 bits for the packed range information > optimization (patch 10): > https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02539.html > CCing Dodji: Dodji; is this reasonable? FWIW, I am definitely to get this (patch 10/10 of the series) if other agrees. I just have some minor questions to ask about that patch and I replied to the patch to ask. As for the "reduction of the space for ordinary maps by a factor of 32, by taking up 5 bits for the packed range information" that you mention, I think it's a trade off I'd live with. Ultimately, if it shows that we really move out of space with this, we should probably explore the impact of just moving to a 64 bits size for source_location. Until then, a possible mitigation strategy could be to add an option to disable the range tracking altogether (even at the preprocessor's lexer level), to provide an escape path to users running low on resources. A bit what we do with -ftrack-macro-expansion=0. Cheers, -- Dodji