> > > So in WPA we can not assume that TYPE_CANONICAL (A) == TYPE_CANONICAL > > > (B) is forever. We also don't do any gimple transforms here, so this is > > > kind of safe, but ugly. > > > > Hmm. But we do > > > > /* alias_ptr_types_compatible_p relies on fact that during LTO > > types do not get refined from WPA time to ltrans. */ > > bp_pack_value (bp, flag_wpa && TYPE_CANONICAL (expr) > > ? TYPE_CXX_ODR_P (TYPE_CANONICAL (expr)) > > : TYPE_CXX_ODR_P (expr), 1); > > > > which I thought would save us from that issue (unless TYPE_CANONICAL > > ends up as the ODR type?). > > Interesting. I sort of remember working on this, but do not remember it > got into mainline. > > TYPE_CANONICAL should not be ODR in this case, since we first compute > canonical typs for non-ODR types only and then walk ODR types and those > conflicting with known non-ODR type get non-ODR canonical. > > > > That said, ideally we'd not re-compute TYPE_CANONICAL during LTRANS > > (but we want to avoid pulling in the canonical itself, just choose > > one that gets put into the LTRANS unit from the set of necessary > > types having the same TYPE_CANONICAL). > > > > > I think types_equal_for_same_type_for_tbaa_p can simply use flag_wpa and > > > we can drop that parameter? I guess that would be less confusing, since > > > the name is kind of misleading anyway. > > > > > > If the fact that WPA may see worse TBAA then ltrans will end up hurting > > > in pratcice we may add extra flag to ODR types when canonical type > > > computation should ignore it and stream it WPA->ltrans to disable the > > > extra precision. > > > > See above ...? > Looking into history the streaming code above got into mainline > (shortly) after I added the ao-ref compare logic to fix ICF issues. > The patch was fixing profiledbootstrap. > https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/337265.html > So probably the check for lto_streaming_safe in > https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/337265.html can be
^^^ wrong cut and paste, I meant types_equal_for_same_type_for_tbaa_p Thanks for noticing this. Honza > dropped next stage1. > > Also remember that with Maritn Liska we had checker that canonical types > do not get refined, which never passed fully (the frontend guided > TYPE_CANONICALs differs in interesting side cases to those computed by > lto canonical type hash), so that is something to get back to as well :( > > Honza > > > > Richard.
