https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note I mentioned in the discussion that TYPE_CANONICAL is used in two ways that
sometimes can have conflicting "conservative settings". It is used for TBAA as
Martin says but it is also used to decide what value conversions are useless.
Basically the idea was that when value conversions are useless then TBAA
behavior should better be the same. But when altering TYPE_CANONICAL to be
"conservative" on the TBAA side you cannot leave the value part out of sight.
TYPE_CANONICAL should generally not be the vehicle to "fix" TBAA, instead
there's the TYPE_ALIAS_SET langhook where in such situation the only choice
that works with LTO is to assign alias-set zero. That's because we lack a way
to communicate TYPE_ALIAS_SET langhook behavior to LTO and LTO instead tries to
mimic cross-FE TBAA by being more aggressive with TYPE_CANONICAL merging. This
might be the problematical decision, that we fail to separate the "value"
TYPE_CANONICAL and the "TBAA" TYPE_CANONICAL as LTO tries to implement "TBAA
merging" (we do not stream the alias-set forests or try to merge those).
I did not anticipate this issue with Ada, but it might be possible to construct
a testcase that's now broken with C as well (even w/o LTO). It's a bit late to
revisit the C23 tag changes now, but we should probably work to revert it
everywhere given the non-transitiveness isn't captured by TYPE_CANONICAL either
and a GIMPLE assign of incompatible objects is now deemed OK.
Sorry for the mess :/ I do remember it was quite difficult to go forward when
reviewing those bits.
