This is the mail archive of the gcc-patches@gcc.gnu.org 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: ICF fixes


> > this patchs fixes few issues in ipa-icf.  First I drop the use of
> > TYPE_CANONICAL because that is no longer part of type compatibility
> > machinery.
> 
> That doesn't seem right, as the check on TYPE_CANONICAL was restored for 
> aggregate types because of the serious issues we found.
> 
> > Second I also hash TYPE_MODE for aggregates, becuase we now always require a
> > match and I check that we don't match types that are incomplete where this
> > would give false negatives.
> 
> We clearly know that TYPE_MODE is far from being sufficient for aggregates.

Yes, this is just a hash.  It should give same equivalence as:
/* Return true if types are compatible from perspective of ICF.  */
bool
func_checker::compatible_types_p (tree t1, tree t2)
{
  if (TREE_CODE (t1) != TREE_CODE (t2))
    return return_false_with_msg ("different tree types");

  if (TYPE_RESTRICT (t1) != TYPE_RESTRICT (t2))
    return return_false_with_msg ("restrict flags are different");

  if (!types_compatible_p (t1, t2))
    return return_false_with_msg ("types are not compatible");

  if (get_alias_set (t1) != get_alias_set (t2))
    return return_false_with_msg ("alias sets are different");

  return true;
}

which does the TYPE_CANONICAL test via types_compatible_p and additionally
check alias set sequivalence.  (this checking needs to be dismantled for
semantic equivalence done via operand_equal_p and TBAA equivalcne done for
loads/stores, but only next stage1).

The hash needs to be stable from compilation to WPA to ltrans.  The problem
here is that TYPE_CANONICAL changes between compilatoin stage and WPA and
thus we end up with different hashes for otherwise same types.
(such as TYPE_CANONICAL of ptrdiff_t being ptrdiff_t at compile stage and
size_t at lto stage).  This corrupts the hashtable.  

The function does deep recurse into aggregates and hash in the fields later
on.

Honza
> 
> -- 
> Eric Botcazou


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