Re: [PATCH] Remove types_compatible_p langhook use from the middle-end

[Diego Novillo <dnovillo at google dot com>]

On Tue, Aug 11, 2009 at 10:59, Richard Guenther<rguenther@suse.de> wrote:
>
> During my quest to implement LTO type merging in terms of the middle-end
> type-system (which I have now given up on) I wondered about TYPE_CANONICAL
> again and noticed some odds.
>
> First it seems it was originally invented to speed up comptypes for C++
> but then re-used for middle-end type compatibility checks. ÂIt seems
> that for TBAA we have to assume that two types T1 and T2 with the same
> canonical type do alias (thus receive the same alias-set number).
> But for some reason we do not care about TBAA conflicts for types
> which require structural equivalence checks ... instead those should
> better get alias-set zero.
>
> Second, in useless_type_conversion_p we decide what conversions we
> want to track explicitly. ÂInstead of implementing structural
> comparisons and carrying them out at each invocation where necessary
> a conservative answer is to require explicit conversions for all
> types involving ones requiring structural equivalence checks.
>
> Third, fortran clears TYPE_CANONICAL sometimes without really
> wanting structural equivalence checks.
>
> For LTO this means we can drop the types_compatible_p langhook
> and are free to implement gimple_types_compatible_p (which should
> be renamed then) in terms of the type-merging task we are doing

Dropping types_compatible_p?  What's wrong with just pointing
types_compatible_p to gimple_types_compatible_p?  That's been the plan
all along.  Not so much removing langhooks, but making gimple appear
as another language which shows up after free_lang_data redirects all
the langhooks.

Perhaps this plan is useful short term, but long term we may want to
banish usage of langhooks altogether.  I don't really have a strong
opinion one way or the other.


> Currently the entanglement of the useless-conversion and TBAA
> effects of TYPE_CANONICAL prevent it being used to record a
> conservatively structurally equivalent variant for making TBAA
> consistent for inter-language LTO (or even slightly buggy
> single-language programs). ÂI'm unsure if we want yet-another
> type linked from each type or if we just should use a hashtable
> for this built from get_alias_set. ÂI guess I will return to
> that once it appears to be the remaining problem.

I agree.  No point tackling both at the same time.


Diego.