Re: [patch] Fix type merging deficiency during WPA

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Jul 6, 2016 at 9:56 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> So this is sth like (invalid C)
>>
>> t.h
>> ---
>> int n;
>> struct X { int x[n]; };
>>
>> t1.c
>> --
>> #include "t.h"
>> struct X x;
>> t2.c
>> --
>> #include "t.h"
>> struct X x;
>>
>> ?
>
> Essentially yes, but with a single definition for 'n' and references to it.
>
>> It's not obvious from the fix (which I think is in the wrong place)
>> which operand_equal/hash
>> call during WPA this is supposed to fix.  So can you please provide a
>> little more context here?
>
> It's called during the canonical type computation invoked from lto_read_decls:
>
>               /* Compute the canonical type of all types.
>                  ???  Should be able to assert that !TYPE_CANONICAL.  */
>               if (TYPE_P (t) && !TYPE_CANONICAL (t))
>                 {
>                   gimple_register_canonical_type (t);
>                   if (odr_type_p (t))
>                     register_odr_type (t);
>                 }
>
> In particular for VLAs:
>
>   /* For array types hash the domain bounds and the string flag.  */
>   if (TREE_CODE (type) == ARRAY_TYPE && TYPE_DOMAIN (type))
>     {
>       hstate.add_int (TYPE_STRING_FLAG (type));
>       /* OMP lowering can introduce error_mark_node in place of
>          random local decls in types.  */
>       if (TYPE_MIN_VALUE (TYPE_DOMAIN (type)) != error_mark_node)
>         inchash::add_expr (TYPE_MIN_VALUE (TYPE_DOMAIN (type)), hstate);
>       if (TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != error_mark_node)
>         inchash::add_expr (TYPE_MAX_VALUE (TYPE_DOMAIN (type)), hstate);
>     }

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.

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.

Richard.

> --
> Eric Botcazou