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] Fix type merging deficiency during WPA

On Wed, Jul 6, 2016 at 12:44 PM, Richard Biener
<> wrote:
> On Wed, Jul 6, 2016 at 12:21 PM, Richard Biener
> <> wrote:
>> On Wed, Jul 6, 2016 at 11:33 AM, Eric Botcazou <> wrote:
>>>> I see.  I think the solution is to perform cgraph/varpool merging
>>>> before attempting to read in
>>>> the global decl stream.  IIRC Micha had (old) patches for this.
>>> How can you merge varpool nodes if you haven't merged types?
> You merge them just in the way the linker instructs you via the
> resolution table.
>>>> But I wonder why we don't tree-merge 'n' here (from my C example) and
>>>> thus figure
>>>> that the type domain of x is equal?  Or is it that 'n' and 'x' are in
>>>> the same SCC (they
>>>> referece each other in some way)?  In this case the bug would be that we
>>>> fail to treat them equal optimistically.  That said, I don't see how
>>>> TYPE_CANONICAL computation is relevant - what is relevant is the failure to
>>>> merge the two types.
>>>> In debugging this I'd start to see if the hashes are not equal or if
>>>> they are equal
>>>> at which node we consider them to differ.
>>> We just have 2 different DECLs with different DECL_UIDs, the definition from a
>>> compilation unit and a reference from another compilation unit, so the hashes
>>> naturally differ too.  What's supposed to have them reconciled at this point?
>> I am talking about tree/SCC merging which happily merges global decls as well.
>> It uses custom hashing (see lto-streamer-out.c:hash_tree) which doesn't hash
>> DECL_UID (obviously).  This merging process should be optimistic for all nodes
>> in the same SCC as well.
>> That said, I expect the types to be tree merged and wonder why they are not.
>> If they were merged they'd obviously share TYPE_CANONICAL because there
>> would be only one type to compute TYPE_CANONICAL for.
> It probably boils down to one unit refering to the DECL with DECL_EXTERNAL set
> and one to the DECL with TREE_STATIC set?  This would mean that
> hashing/comparing
> should be set up to "merge" those but the merging ultimatively rejected by some
> toplevel logic (so we get users merged).  But as said, early symtab
> merging would
> fix this as well.

So sth like

Index: gcc/lto-streamer-out.c
--- gcc/lto-streamer-out.c      (revision 238039)
+++ gcc/lto-streamer-out.c      (working copy)
@@ -996,7 +996,7 @@ hash_tree (struct streamer_tree_cache_d
     hstate.add_flag (TREE_NO_WARNING (t));
   hstate.add_flag (TREE_NOTHROW (t));
-  hstate.add_flag (TREE_STATIC (t));
+  //hstate.add_flag (TREE_STATIC (t));
   hstate.add_flag (TREE_PROTECTED (t));
   hstate.add_flag (TREE_DEPRECATED (t));
   if (code != TREE_BINFO)
@@ -1050,7 +1050,7 @@ hash_tree (struct streamer_tree_cache_d
       hstate.add_flag (DECL_ARTIFICIAL (t));
       hstate.add_flag (DECL_USER_ALIGN (t));
       hstate.add_flag (DECL_PRESERVE_P (t));
-      hstate.add_flag (DECL_EXTERNAL (t));
+      //hstate.add_flag (DECL_EXTERNAL (t));
       hstate.add_flag (DECL_GIMPLE_REG_P (t));
       hstate.commit_flag ();
       hstate.add_int (DECL_ALIGN (t));
Index: gcc/lto/lto.c
--- gcc/lto/lto.c       (revision 238039)
+++ gcc/lto/lto.c       (working copy)
@@ -1263,7 +1263,8 @@ compare_tree_sccs_1 (tree t1, tree t2, t
     tree t1_ = (E1), t2_ = (E2); \
     if (t1_ != t2_ \
        && (!t1_ || !t2_ \
-           || !TREE_VISITED (t2_) \
+           || (!TREE_VISITED (t2_) \
+               && !same_decls (t1_, t2_)) \
            || (!TREE_ASM_WRITTEN (t2_) \
                && !compare_tree_sccs_1 (t1_, t2_, map)))) \
       return false; \

plus the magic new function same_decls which would check if the trees are
var/function decls with the same assembler name. The function can't use
the cgraph as that is not yet read in unfortunately - I still think we should
do that so we can see the prevailing nodes early.


> Richard.
>> Richard.
>>> The TYPE_CANONICAL computation is relevant because, with GCC 6, the criterion
>>> for compatibility of pointer types is the alias set, which is based on the
>>> TYPE_CANONICAL of the pointed-to type, so we fail to merge pointer types
>>> because warn_type_compatibility_p returns non-zero if TYPE_CANONICAL differs.
>>> --
>>> Eric Botcazou

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