This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Fix type merging deficiency during WPA
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 6 Jul 2016 12:21:16 +0200
- Subject: Re: [patch] Fix type merging deficiency during WPA
- Authentication-results: sourceware.org; auth=none
- References: <1644035.nvA1iejZSU@polaris> <1814441.lYRMngSIKU@polaris> <CAFiYyc29+-YPosTkOhkxw0_YAJgwJspyOGgyVv-QSw1HH0yu2A@mail.gmail.com> <6067632.J78nz0hHfJ@polaris>
On Wed, Jul 6, 2016 at 11:33 AM, Eric Botcazou <firstname.lastname@example.org> 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.
> 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