https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #9) > Do you really need to hash it on TYPE_CANON, rather than just on whether the > type is > TYPE_STRUCTURAL_EQUALITY_P or not? It's enough for the testcases here, I didn't try to convince myself it's safe but of course it's better than what we do right now. So we can try that as well. > I'm worried that always computing the TYPE_CANON before calling > type_hash_canon is going to be quite expensive, while just figuring out if > it should have TYPE_STRUCTURAL_EQUALITY_P or not should be cheaper. If it > should have > TYPE_STRUCTURAL_EQUALITY_P, we'd SET_TYPE_STRUCTURAL_EQUALITY, otherwise set > TYPE_CANONICAL (t) = t; (I think that is what we generally get from > make_node), look up > and recompute TYPE_CANONICAL if TYPE_CANONICAL (t) == t. I'd like to make it obvious at least that we only alter TYPE_CANONICAL if we were the one building 't' in the first place. The layouting of types also seems to be redundant now as that's done by type_hash_canon. Luckily there are not too many callers. It's a bit late for 14.1, so we can refactor things on trunk and then backport later.
