* ICF fixes
@ 2015-11-21 4:26 Jan Hubicka
2015-11-21 10:41 ` Eric Botcazou
0 siblings, 1 reply; 3+ messages in thread
From: Jan Hubicka @ 2015-11-21 4:26 UTC (permalink / raw)
To: gcc-patches
Hi,
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.
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.
Second change is in func_checker::compatible_types_p where I disabled comparing
of alias sets of types that do not have alias sets (and thus can never be read).
I hoped to switch ipa-icf-gimple.c to use of operand_equal_p and drop all such
wrong type mathcing, but I suppose it will need to wait for next stage1.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-icf.c (sem_item::add_type): Do not look for TYPE_CANONICAL;
do not check AGGREGATE_TYPE_P when adding TYPE_MODE;
Check that all record types are complete.
* ipa-icf-gimple.c (func_checker::compatible_types_p): Do not
compare alias sets for types w/o alias sets.
Index: ipa-icf.c
===================================================================
--- ipa-icf.c (revision 230683)
+++ ipa-icf.c (working copy)
@@ -1543,11 +1543,8 @@ sem_item::add_type (const_tree type, inc
}
type = TYPE_MAIN_VARIANT (type);
- if (TYPE_CANONICAL (type))
- type = TYPE_CANONICAL (type);
- if (!AGGREGATE_TYPE_P (type))
- hstate.add_int (TYPE_MODE (type));
+ hstate.add_int (TYPE_MODE (type));
if (TREE_CODE (type) == COMPLEX_TYPE)
{
@@ -1574,6 +1571,7 @@ sem_item::add_type (const_tree type, inc
}
else if (RECORD_OR_UNION_TYPE_P (type))
{
+ gcc_checking_assert (COMPLETE_TYPE_P (type));
hashval_t *val = optimizer->m_type_hash_cache.get (type);
if (!val)
Index: ipa-icf-gimple.c
===================================================================
--- ipa-icf-gimple.c (revision 230683)
+++ ipa-icf-gimple.c (working copy)
@@ -233,7 +233,15 @@ func_checker::compatible_types_p (tree t
if (!types_compatible_p (t1, t2))
return return_false_with_msg ("types are not compatible");
- if (get_alias_set (t1) != get_alias_set (t2))
+ /* We do a lot of unnecesary matching of types that are not being
+ accessed and thus do not need to be compatible. In longer term we should
+ remove these checks on all types which are not accessed as memory
+ locations.
+
+ For time being just avoid calling get_alias_set on types that are not
+ having alias sets defined at all. */
+ if (type_with_alias_set_p (t1) && type_with_alias_set_p (t2)
+ && get_alias_set (t1) != get_alias_set (t2))
return return_false_with_msg ("alias sets are different");
return true;
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ICF fixes
2015-11-21 4:26 ICF fixes Jan Hubicka
@ 2015-11-21 10:41 ` Eric Botcazou
2015-11-21 18:20 ` Jan Hubicka
0 siblings, 1 reply; 3+ messages in thread
From: Eric Botcazou @ 2015-11-21 10:41 UTC (permalink / raw)
To: Jan Hubicka; +Cc: gcc-patches
> 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.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ICF fixes
2015-11-21 10:41 ` Eric Botcazou
@ 2015-11-21 18:20 ` Jan Hubicka
0 siblings, 0 replies; 3+ messages in thread
From: Jan Hubicka @ 2015-11-21 18:20 UTC (permalink / raw)
To: Eric Botcazou; +Cc: Jan Hubicka, gcc-patches
> > 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-21 18:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-21 4:26 ICF fixes Jan Hubicka
2015-11-21 10:41 ` Eric Botcazou
2015-11-21 18:20 ` Jan Hubicka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).