This is the mail archive of the
mailing list for the GCC project.
Re: [EXT] Re: Comparing types at LTO time
- From: Gary Oblock <goblock at marvell dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Jan Hubicka <hubicka at ucw dot cz>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 9 Jan 2020 20:36:00 +0000
- Subject: Re: [EXT] Re: Comparing types at LTO time
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=36k2D9A8pERltg8K/RMfQBu3mMAm3h+kMbfxtGGTGdk=; b=caMTpEhiVWnYMrTESYMNBtXs7xvd4tEMliSRt/LwDVFeIaVoyMPmAi+vEvdGNF07qIE2HrO7tj7YAWRXtIegnbblPFG47/tKfiEHukbns+Gql2pbN30j6GXO4aLGuGLTzQDVSwQbyAUw4noBy5DhB8MD0zTzikloIqjUWJQj7tMRqKenNd1pSde3i3EXnmV8veWjQyjO6mQiBM8QPPfKkkrWKrPURY88gG6eSF80DA/+tKC8B6/EEDNjXn+vLt4KKLvSUhkqTTVl7snkwDPph0IyvLXfq+WYRWciBwX0abM2S3in7e0yE8AVsIncD+H5vK0blG5GWJHvvZLnZ4kpcQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FnIl0smlE4W8alI+8licj3VWyJzWdbRY5BMwkTCHaY4s3GOuaQuCEQTVFZqs88hnmguHpfq6u/FEc5ANaAf94PSxIQz9Bfzy+aM3xevrCOCU8Mv5cM82Q5MDoL3v0Vpz7C0QYj1k28TN4y6pSZcEgE5EkRoLK4eLufn0yIZ9cHVBcuI/v+nAqK6WgwfgkxHIaJ5Cx1z3d6x785xl1+beBL/Z7o1BwRnBOblDNNYC+CJXwI1SGSkT73E+Bxv6cetThF7VOOkSGslI6a8ccVBiniao8eLKEjuGftn8a/Chp8roeRVi/MZQ3dyWBXyZ5azGATBgR2SKs1R2YSgEIXPEzg==
- References: <BY5PR18MB3409528680E154A19FB29C17B9390@BY5PR18MB3409.namprd18.prod.outlook.com> <20200109085318.GK4674@kam.mff.cuni.cz>,<CAFiYyc1FZJyU1xySuzy7vv+7+o-cx_OJTW2dntjWHjQhkyz6Rw@mail.gmail.com>
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.
From: Richard Biener <email@example.com>
Sent: Thursday, January 9, 2020 3:51 AM
To: Jan Hubicka <firstname.lastname@example.org>
Cc: Gary Oblock <email@example.com>; firstname.lastname@example.org <email@example.com>
Subject: [EXT] Re: Comparing types at LTO time
On Thu, Jan 9, 2020 at 9:53 AM Jan Hubicka <firstname.lastname@example.org> 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.
> > Thanks,
> > Gary Oblock