From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19151 invoked by alias); 10 Jan 2020 10:30:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 19134 invoked by uid 89); 10 Jan 2020 10:30:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HTo:D*marvell.com X-HELO: mail-lf1-f52.google.com Received: from mail-lf1-f52.google.com (HELO mail-lf1-f52.google.com) (209.85.167.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Jan 2020 10:30:08 +0000 Received: by mail-lf1-f52.google.com with SMTP id v201so1060381lfa.11 for ; Fri, 10 Jan 2020 02:30:08 -0800 (PST) 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=G46X6C4raCyYyqo15FGOGVNvRppzDlbBdWPB5q5ikis=; b=obQkWO8btcBRf7XaWa0mNUsTxnl6aL+d3PQEFDUBsIaTfw5rGM+UDmzzYR6ROcFRfF Sxf3DLKkdluTA252Tp2kOnzjWxtaXIVWNjUbwWrpASkZYPpQWW8curMf1Qomd1uq4J/s mW4EMMDIwXQSM6kuYnXeP9J4j69eTw+AQKDDq+y8b3sWynBQa37YQ8rxuRRn2MFm8S9R r05SbbtFByopnUrKNKcfkOU9M72FgzednvB+MSzl75uRQp8fjqj6u0l3L236TCO9EMN9 6HBoPAsFeL9JyLUWUEvRDcsPObwr9cMI8wmD5TJ9XysQvukUh91479qv+LDZ5qkG1fmT K3lA== MIME-Version: 1.0 References: <20200109085318.GK4674@kam.mff.cuni.cz> In-Reply-To: From: Richard Biener Date: Fri, 10 Jan 2020 10:30:00 -0000 Message-ID: Subject: Re: [EXT] Re: Comparing types at LTO time To: Gary Oblock Cc: Jan Hubicka , "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00109.txt.bz2 On Thu, Jan 9, 2020 at 9:36 PM Gary Oblock wrote: > > Richard, > > Alas, when doing structure reorg I have to be able to know some > arbitrary use of variable X in some GIMPLE expression is of a > type that needs to be transformed in that given expression. I see no > way around this. Sure, if you view it as it transforming a type. I see it as transforming the layout of a specific object so all you need to know is whether an arbitrary memory access accesses the very object - which you could, if you face accesses you can't analyze, even check at runtime to some extent (worst case by providing a copy in/out to a temporary with the old layout). Richard. > ________________________________ > From: Richard Biener > Sent: Thursday, January 9, 2020 3:51 AM > To: Jan Hubicka > Cc: Gary Oblock ; gcc@gcc.gnu.org > Subject: [EXT] Re: Comparing types at LTO time > > External Email > > ---------------------------------------------------------------------- > On Thu, Jan 9, 2020 at 9:53 AM Jan Hubicka wrote: > > > > > There doesn't seem to be a way to compare types at LTO time. The functions > > > same_type_p and comptypes are front end only if I'm not totally confused > > > (which is quite possible) and type_hash_eq doesn't seem to apply for > > > structure types. Please, any advice would be welcome. > > > > At LTO time it is bit hard to say what really is the "same type". We > > have multiple notions of equivalence: > > 1) TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2) > > means that both types were equal in tree merging at stream in, this > > means that their IL representaiton is identical. > > > > This will lead to "false" for types that are same bud did not get > > merged for various reasons. One such valid reason, for example, is > > visibility of associated virtual tables > > 2) types_types_same_for_odr returns true if types are considered same > > by C++ one definition rule. This is reliable but works only for C++ > > types with names (structures and unions) > > 3) same_type_for_tbaa returns true if types are equivalent for type > > based alias analysis. It returns true in much more cases than 1 > > but is too coarse if you want to do datastructure changes. > > > > So in general this is quite hard problem (and in fact I started to play > > with ODR types originally to understand it better). I would suggest > > starting with 1 if you want to rewrite types and eventually add a new > > comparsion once pass does something useful. > > > > Richard may have some extra insights. > > My advice would be to not go down the route that requires comparing types > since I'm not sure you can do that conservatively since you at the same > time may not say two types are equal when they are not nor miss two > equal types. For example if you have a C TU and a Fortran TU there's > defined interoperability but the actual type representations are distinct > enough so that Honzas equality according to 1) doesn't trigger (nor does 2), > but 3) does, but that will identify too many types as equal. > > Richard. > > > Honza > > > > > > Thanks, > > > > > > Gary Oblock > > >