From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126540 invoked by alias); 16 Aug 2019 09:11:34 -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 126532 invoked by uid 89); 16 Aug 2019 09:11:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=outcome X-HELO: mail-lf1-f68.google.com Received: from mail-lf1-f68.google.com (HELO mail-lf1-f68.google.com) (209.85.167.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Aug 2019 09:11:24 +0000 Received: by mail-lf1-f68.google.com with SMTP id a30so3561230lfk.12 for ; Fri, 16 Aug 2019 02:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SLiscThWdl+X7zu7sQGDuVCAY4d82bBU1C2KlWdQJ2Q=; b=fzXGxT+W9fFKEl3bM9Mhi7vx6RH5We/9mSuv6xpX0G+Ve6nC2ksORixqIkAhU+9PH7 hCrOXtaAUxUM/XdRCQtb0lLdZDt0a41opvPBn1Z3zjry+Qb5W5c5Um/Pyydo9t2IxGY3 HDepbazboJhLF679zO+wbKYgtA2NytoolGfky3ziMf6OytO4VR+uDOAt/ZMPQ8pCKNk4 SBFASrRM8jB2dMgzqXKtK9KEDzEHLGgDVrxQhd+d0RlbyZO1+uYVZi3qnIXgGNvxzozw /D9Ee5VD2CZLlmj+ONagg5BqVB8rzgaL1+xVBo2XEpEnSixZFIQk/D1b93oXhMY4ILRN bHhQ== MIME-Version: 1.0 References: <94fde27bc6206d87448943f5d331c35fcd69901f.1565105736.git.mliska@suse.cz> <20190815141727.m4qismzapuvy2vcy@kam.mff.cuni.cz> In-Reply-To: <20190815141727.m4qismzapuvy2vcy@kam.mff.cuni.cz> From: Richard Biener Date: Fri, 16 Aug 2019 09:28:00 -0000 Message-ID: Subject: Re: [PATCH 2/9] operand_equal_p: add support for FIELD_DECL To: Jan Hubicka Cc: Martin Liska , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg01155.txt.bz2 On Thu, Aug 15, 2019 at 4:17 PM Jan Hubicka wrote: > > > On Tue, Aug 6, 2019 at 5:44 PM Martin Liska wrote: > > > > > > > > > gcc/ChangeLog: > > > > So I suppose this isn't to call operand_equal_p on two FIELD_DECLs > > but to make two COMPONENT_REFs "more equal"? If so I then > > yes. The patch originates from my original patchset I believe and it is > what ICF does. > > I suggest to make this change "local" to the COMPONENT_REF handling. > > This also interacts with path-based disambiguation so you want to make > > sure to only make things equal here iff it wouldn't change the outcome > > of path-based analysis. Honza? > > Indeed this can be handled as part of COMPONENT_REF match. > Access path oracle here basically checks: > 1) that MEM_REF type matches (we want predicate for this) > 2) if it finds type match via same_type_for_tbaa and then it applies > the assumption about disjointness or overlap > > So I guess ideally we should > > 1) do matching part of COMPONENT_REF > 2) compare OFFSET, BIT_OFFSET > This establishes that the access has same semantics. > 3) for -fno-strict-aliasing be happy > 4) for -fstrict-aliaisng check if access path applies (we should export > predicate from tree-ssa-alias as discussed earlier) > 5) compare types by same_type_for_tbaa_p Ick. This smells like a layering violation to me. IMHO this extended equality handling should be handled with the overloading/callback and not in native operand_equal_p. Either on the level of the COMPONENT_REF itself (sounds like that would be needed) or the FIELD_DECL. Not sure if the above suggestions make it neccessary to look at more than a single COMPONENT_REF/FIELD_DECL in the access path. If so then watch out for quadraticness as operand_equal_p traverses a reference chain... Richard. > Honza