Re: compatibility of structs/unions/enums in the middle end

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin
<Martin.Uecker@med.uni-goettingen.de> wrote:
>
> Am Mittwoch, den 02.10.2019, 12:47 +0200 schrieb Richard Biener:
> > On Wed, Oct 2, 2019 at 12:46 PM Richard Biener
> > <richard.guenther@gmail.com> wrote:
> > >
> > > On Tue, Oct 1, 2019 at 7:49 PM Uecker, Martin
> > > <Martin.Uecker@med.uni-goettingen.de> wrote:
>
> ...
> > > >
> > > > In particular, the idea is to make structs (+ unions, enums)
> > > > with the same tag and the same members compatible. The
> > > > current C standards says that such structs are compatible
> > > > between different TUs but not inside the same TU, which
> > > > is very strange and - as pointed out by Joseph
> > > > in DR314 - this leads to "interesting" scenarios
> > > > where types across different TU cannot be partitioned
> > > > into equivalence classes in a consistent way.
> ...
>
> > > > I would appreciate any information about how to
> > > > approach this.
> > >
> > > The frontend either needs to have the same internal
> > > type representation for both or provide the middle-end
> > > with unification of compatible types via the TYPE_CANONICAL
> > > mechanism (that's what the C++ FE does in similar circumstances).
> > >
> > > That is, the TBAA machinery relies on TYPE_CANONICAL (TYPE_MAIN_VARIANT (st1))
> > > == TYPE_CANONICAL (TYPE_MAIN_VARIANT (st2))
> > > (or requivalent TYPE_MAIN_VARIANT if that's already the case).
>
> Yes, this is what I assumed from looking at the code. The problem
> is that the front end would need to go over all types and set
> TYPE_CANONICAL.

Yes.

> This seems easy to do on the fly whenever the front
> end needs to compare types anyway, but this would not be enough
> as also types which appear unrelated to the front end (e.g. two
> types declared in separate local scopes) could be compatible.
> To identify these types would require searching a data structure
> of all such types in the front end every time a new tagged type
> is created. This would not be too difficult to implement.
>
> On the other hand, the situation with this propsoal for such types
> is then very similar to any other complex type expressions which
> need to compared structurally in the middle end. So what I am
> wondering is whether it would be possible to do such comparisons
> in the middle end also for tagged types?

The middle-end ensures there's only one such type via hashing
types via type_hash_canon.

> Finally, how does LTO does it? It somehow also needs to unify
> different tagged types? Could we reuse this mechanism somehow?

LTO structurally merges types via TYPE_CANONICAL.  But rules
for merging depend on language semantics, too much merging
hinders optimization.

> > Btw, for you example, how do you expect debug information to look like?
> > Would there be two type definitions that are not related?
>
> I don't know yet. This is why I am trying to implement it, to
> figure out all these practical issues. How does it work now for
> tagged types in different TUs that are compatible?

You get two copies.

Richard.

> Best,
> Martin