Hello, On Tue, 7 Apr 2020, Erick Ochoa wrote:
> > So, when you want to compare types use useless_type_conversion_p (for > > equivalence you need useless(a,b) && useless(b,a)). In particular, > > for record types T it's TYPE_CANONICAL(T) that needs to be > > pointer-equal. (I.e. you could hard-code that as well, but it's > > probably better to use the existing predicates we have). Note that > > useless_type_conversion_p is for the middle-end type system (it's > > actually one part of the definition of that type system), i.e. it's > > language agnostic. If you need language specific equality you would > > have to use a different approach, but given that you're adding IPA > > passes you probably don't worry about that. > > I've been using TYPE_MAIN_VARIANT(T) as opposed to TYPE_CANONICAL(T). > This was per the e-mail thread: > https://gcc.gnu.org/legacy-ml/gcc/2020-01/msg00077.html . Well, Honza correctly said that TYPE_MAIN(a) == TYPE_MAIN(b) implies a and b to have the same representation. But that doesn't imply the reserve direction, so that hint was somewhat misleading. > I am not 100% sure what the differences are between these two yet, Basically TYPE_MAIN_VARIANT "removes" qualifiers, i.e. the main variant is always the one without const/volatile. TYPE_CANONICAL is defined for record types and being the same means they have the same representation as well, and are regarded the same from a type aliasing p.o.v. In comparison to MAIN_VARIANT a non-equal CANONICAL pointer does imply non-equivalence of the types, so you can infer something from comparing CANONICAL. That is true for the types that do have TYPE_CANONICAL set, the others need structural comparison. See the docu of TYPE_CANONICAL and TYPE_STRUCTURAL_EQUALITY_P in tree.h. > but I think TYPE_CANONICAL(T) was not helpful because of typedefs? I > might be wrong here, it has been a while since I did the test to see > what worked. > > Using TYPE_MAIN_VARIANT(T) has gotten us far in an optimization we are > working on, but I do think that a custom type comparison is needed now. Well, it really depends on what specific definition of type equality/equivalence/compatibility you need, and for what. Do you want to differ between typedefs or not, do you regard structs of same members but different tag as equal or not, and so on. > I do not believe I can use useless_type_conversion_p because I need a > partial order in order to place types in a set. Apart from the fact that useless_type_conversion_p _is_ a partial order, do you mean the internal requirement of a set implementation relying on some partial order? Well, yeah, I wouldn't necassarily expect you can use predicates defining a semantic order on items to be usable as an internal implementation requirement of some random data structure. I don't know what exactly you need the sets for, so I don't know if you could just use the usual pointer sets that would then hold possibly multiple "same" trees, where the same-ness would only be used later when pulling elements out of the set. Ciao, Michael.
