This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]