This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [EXT] Re: Comparing types at LTO time

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).


> ________________________________
> From: Richard Biener <>
> Sent: Thursday, January 9, 2020 3:51 AM
> To: Jan Hubicka <>
> Cc: Gary Oblock <>; <>
> 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:
> >     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
> > >

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]