On Mon, Apr 15, 2024 at 01:33:18PM +0200, Richard Biener wrote:
> > But looking at all the build_variant_type_copy callers and the call itself,
> > the call itself sets TYPE_CANONICAL to the TYPE_CANONICAL of the type on
> > which it is called and the only caller I can find that changes
> > TYPE_CANONICAL sometimes is build_qualified_type.
> > So, I'd hope that normally all variant types of an aggregate type (or
> > pointer type) have the same TYPE_CANONICAL if they have the same TYPE_QUALS
> > and if they have it different, they have TYPE_CANONICAL of
> > build_qualified_type of the base TYPE_CANONICAL.
>
> The middle-end assumes that TYPE_CANONICAL of all variant types are
> the same, for TBAA purposes it immediately "puns" to
> TYPE_CANONICAL (TYPE_MAIN_VARIANT (..)). It also assumes that
> the canonical type is not a variant type. Note we never "honor"
> TYPE_STRUCTURAL_EQUALITY_P on a variant type (because we don't look
> at it, we only look at whether the main variant has
> TYPE_STRUCTURAL_EQUALITY_P).
>
> Thus, TYPE_CANONICAL of variant types in principle doesn't need to be
> set (but not all places might go the extra step looking at the main
> variant before accessing TYPE_CANONICAL).
The patch as posted passed bootstrap/regtest.
Even if the middle-end doesn't look at TYPE_CANONICAL on anything but
TYPE_MAIN_VARIANT, for the case of say POINTER_TYPE to TYPE_READONLY
qualified struct (like struct S const *) the pointer still has
TYPE_CANONICAL based on the qualified type rather than main variant,
so not recomputing TYPE_CANONICAL for the variant would have consequences
on TYPE_CANONICAL for types derived from those variant types.
So, if I have
struct S;
const struct S *p;
struct S { int s; };
const struct S q[10];
then if I don't recompute TYPE_CANONICAL for const struct S, both the
const struct S * TYPE_CANONICAL would remain TYPE_STRUCTURAL_EQUALITY_P,
but also the ARRAY_TYPE would have it as well, even when it has been
created only after finalizing the type.
Jakub
