On Thu, Jan 9, 2020 at 9:36 PM Gary Oblock <gobl...@marvell.com> 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 <richard.guent...@gmail.com> > Sent: Thursday, January 9, 2020 3:51 AM > To: Jan Hubicka <hubi...@ucw.cz> > Cc: Gary Oblock <gobl...@marvell.com>; gcc@gcc.gnu.org <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 <hubi...@ucw.cz> 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 > > >
