From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67218 invoked by alias); 9 Jul 2019 21:02:30 -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 67209 invoked by uid 89); 9 Jul 2019 21:02:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wm1-f48.google.com Received: from mail-wm1-f48.google.com (HELO mail-wm1-f48.google.com) (209.85.128.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Jul 2019 21:02:28 +0000 Received: by mail-wm1-f48.google.com with SMTP id v19so159240wmj.5 for ; Tue, 09 Jul 2019 14:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:in-reply-to:references:mime-version:content-transfer-encoding :subject:to:cc:from:message-id; bh=qen2NhcBJ45bimqXtqkwlWuSeLnqRTYHCMZYd4nhKVY=; b=g6li8ilHLz/A7caIG/TpIEJeu7fOsyCb/P3yVDf7DNu8nql4AH64VLegvmbYWOArwm ueBypltTb8xv7RiCUdVYqXuQIlfrwYTtiHmoGHAsmM+FDDJDxS1FdVrMs+gnyV54TTqF IzgVYorvlZV2rVy++dIvjHfC0+TLKZq0IVCbsXDjiHJ5jvUc5EU9FGFRX8DA4BSa4lm0 vgrKcfsMJ6ING1WuY2RsPzRDhoEHkcVB6x51845n0b/0jL02D2Y3onuWlWuK3vHh5/DO XgEJY1v6HWpSRZjPfZWDk78tEb24jTvf0JTQt5oCq0OBkjhoqjcEhmjUryt7L2z0bgy7 ak5g== Return-Path: Received: from [100.102.121.182] (089144197018.atnat0006.highway.a1.net. [89.144.197.18]) by smtp.gmail.com with ESMTPSA id l2sm102392wmj.4.2019.07.09.14.02.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 14:02:25 -0700 (PDT) Date: Tue, 09 Jul 2019 21:03:00 -0000 In-Reply-To: References: <20190708072649.vqd5u6jxsz5ybtt7@kam.mff.cuni.cz> <20190709114917.qva4nb2h7j5vzdur@kam.mff.cuni.cz> <20190709133008.tph5qhzvwis6ciz3@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Make nonoverlapping_component_refs work with duplicated main variants To: gcc-patches@gcc.gnu.org,Richard Biener ,Jan Hubicka CC: d@dcepelik.cz From: Bernhard Reutner-Fischer Message-ID: <45CE5AFB-5FBC-4044-91E0-B89DB1B84407@gmail.com> X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00734.txt.bz2 On 9 July 2019 15:37:30 CEST, Richard Biener wrote: >On Tue, 9 Jul 2019, Jan Hubicka wrote: > >> Hi, >> this is updated variant I am testing. >> It documents better how function works and streamlines the checks. >>=20 >> OK assuming it passes the tests? >>=20 >> Honza >>=20 >> Index: tree-ssa-alias.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- tree-ssa-alias.c (revision 273193) >> +++ tree-ssa-alias.c (working copy) >> @@ -1128,6 +1128,91 @@ aliasing_component_refs_p (tree ref1, >> return false; >> } >>=20=20 >> +/* FIELD1 and FIELD2 are two fields of component refs. We assume >> + that bases of both component refs are >> + (*) are either equivalent or they point to different objects. > >are either equivalent(*) or not overlapping > >> + We do not assume that FIELD1 and FIELD2 are of same type. > >that the containers of FIELD1 and FIELD2 are of the same type? > >> + >> + Return 0 if FIELD1 and FIELD2 satisfy (*). >> + This is the case when their offsets are the same. > >Hmm, so when the offsets are the same then the bases are equivalent? >I think you want to say > > Return 0 if in case the component refs satisfy (*) we > know FIELD1 and FIELD2 are overlapping exactly. > >> + Return 1 if FIELD1 and FIELD2 are non-overlapping. >> + >> + Return -1 otherwise. >> + >> + Main difference between 0 and -1 is to let >> + nonoverlapping_component_refs_since_match_p discover the >semnatically > >semantically > >otherwise looks good now. > >Thanks, >Richard. > >> + equivalent part of the access path. >> + >> + Note that this function is used even with -fno-strict-aliasing >> + and makes use of no TBAA assumptions. */ >> + >> +static int >> +nonoverlapping_component_refs_p_1 (const_tree field1, const_tree >field2) >> +{ >> + /* If both fields are of the same type, we could save hard work of >> + comparing offsets. */ >> + tree type1 =3D DECL_CONTEXT (field1); >> + tree type2 =3D DECL_CONTEXT (field2); >> + >> + if (DECL_BIT_FIELD_REPRESENTATIVE (field1)) >> + field1 =3D DECL_BIT_FIELD_REPRESENTATIVE (field1); >> + if (DECL_BIT_FIELD_REPRESENTATIVE (field2)) >> + field2 =3D DECL_BIT_FIELD_REPRESENTATIVE (field1); Typo: s/field1/field2/ >> + >> + /* ??? Bitfields can overlap at RTL level so punt on them. >> + FIXME: RTL expansion should be fixed by adjusting the access >path >> + when producing MEM_ATTRs for MEMs which are wider than=20 >> + the bitfields similarly as done in set_mem_attrs_minus_bitpos.=20 >*/ >> + if (DECL_BIT_FIELD (field1) && DECL_BIT_FIELD (field2)) >> + return -1; That's a pity. thanks,