This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH] Remove types_compatible_p langhook use from the middle-end
On Wed, 12 Aug 2009, Diego Novillo wrote:
> 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.
Well, the langhook is not really necessary. The gimple_types_compatible_p
variant is so much designed for type-merging that trying to make it
suitable for the langhook looks odd (well, that's where I thought it
must be the same as useless_type_conversion_p - but that got me on
the wrong track).
> 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.
Yeah. I'll apply the patch later today to the trunk, testing went well.
Thanks,
Richard.