[patch] Fix type merging deficiency during WPA

[Richard Biener]

On Wed, Jul 6, 2016 at 11:33 AM, Eric Botcazou <ebotcazou@adacore.com> 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?
>
>> 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.

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