This is the mail archive of the mailing list for the GCC 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: {tree-ssa] Fixes re multiple type nodes from IMA

On Mar 11, 2004, at 2:47 PM, Richard Henderson wrote:
On Wed, Mar 10, 2004 at 05:49:50PM -0800, Dale Johannesen wrote:
+ /* This compares two types for equivalence ("compatible" in C-based languages).
+ This routine should only return 1 if it is sure. It should not be used
+ in contexts where erroneously returning 0 causes problems. */
+ int
+ lhd_types_eq_p (tree x, tree y)
+ {
+ return x == y;
+ }

I'd prefer "compatible" in the function name as well for emphasis.

I have no problem with this, but does that concept exist in non-C based languages?

I think you should move the TYPE_MAIN_VARIANT bit into the hook;
that'll clean up most users:


!   if (!(*lang_hooks.types_eq_p)(TYPE_MAIN_VARIANT(orig_type),
! 				TYPE_MAIN_VARIANT(elt_type)))

if (lang_hooks.types_eq_p (orig_type, elt_type))

No need for (*foo) either; we're C90 now.


+       /* Make sure the FIELD_DECL is actually a field in the type on
+ 	 the lhs.  In cases with IMA it is possible that it came
+ 	 from another, equivalent type at this point.  We have
+ 	 already checked the equivalence in this case.
+ 	 For unions, we must match on name; do this for structs
+ 	 also for simplicity.  */

Some fields don't have names. This is particularly common with compiler-generated structures. I think I'd feel better if you matched field type and offset.

OK, I guess. You won't necessarily get the corresponding field for
unions doing that, but I suppose it doesn't matter. (I see that SRA
doesn't currently do unions anyway, but it could in some cases. It may be
a small enough win that nobody will ever do it though.)

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