From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74205 invoked by alias); 15 Nov 2016 19:47:18 -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 74194 invoked by uid 89); 15 Nov 2016 19:47:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=evidence, distance X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Nov 2016 19:47:16 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 0B4D3812FB; Tue, 15 Nov 2016 20:47:15 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUg4_AOHuKVh; Tue, 15 Nov 2016 20:47:14 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id D903A812D4; Tue, 15 Nov 2016 20:47:14 +0100 (CET) From: Eric Botcazou To: Richard Sandiford Cc: gcc-patches@gcc.gnu.org Subject: Re: Add a mem_alias_size helper class Date: Tue, 15 Nov 2016 19:47:00 -0000 Message-ID: <3239159.3ZvhITNy1m@polaris> User-Agent: KMail/4.14.10 (Linux/3.16.7-48-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: <87mvh03f20.fsf@e105548-lin.cambridge.arm.com> References: <87mvh03f20.fsf@e105548-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2016-11/txt/msg01528.txt.bz2 > alias.c encodes memory sizes as follows: > > size > 0: the exact size is known > size == 0: the size isn't known > size < 0: the exact size of the reference itself is known, > but the address has been aligned via AND. In this case > "-size" includes the size of the reference and the worst-case > number of bytes traversed by the AND. > > This patch wraps this up in a helper class and associated > functions. The new routines fix what seems to be a hole > in the old logic: if the size of a reference A was unknown, > offset_overlap_p would assume that it could conflict with any > other reference B, even if we could prove that B comes before A. > > The fallback CONSTANT_P (x) && CONSTANT_P (y) case looked incorrect. > Either "c" is trustworthy as a distance between the two constants, > in which case the alignment handling should work as well there as > elsewhere, or "c" isn't trustworthy, in which case offset_overlap_p > is unsafe. I think the latter's true; AFAICT we have no evidence > that "c" really is the distance between the two references, so using > it in the check doesn't make sense. > > At this point we've excluded cases for which: > > (a) the base addresses are the same > (b) x and y are SYMBOL_REFs, or SYMBOL_REF-based constants > wrapped in a CONST > (c) x and y are both constant integers > > No useful cases should be left. As things stood, we would > assume that: > > (mem:SI (const_int X)) > > could overlap: > > (mem:SI (symbol_ref Y)) > > but not: > > (mem:SI (const (plus (symbol_ref Y) (const_int 4)))) Frankly this seems to be an example of counter-productive C++ization: the class doesn't provide any useful abstraction and the code gets obfuscated by all the wrapper methods. Moreover it's mixed with real changes so very hard to review. Can't you just fix what needs to be fixed first? -- Eric Botcazou