This is the mail archive of the
mailing list for the GCC project.
Re: [EXT] Re: Comparing types at LTO time
On Thu, Jan 9, 2020 at 9:36 PM Gary Oblock <firstname.lastname@example.org> wrote:
> 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
> 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
> External Email
> 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.
> > Honza
> > >
> > > Thanks,
> > >
> > > Gary Oblock
> > >