On Wed, Oct 2, 2019 at 1:57 PM Uecker, Martin <martin.uec...@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.guent...@gmail.com> wrote: > > > > > > On Tue, Oct 1, 2019 at 7:49 PM Uecker, Martin > > > <martin.uec...@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
