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