Re: PATCH: PR lto/50568: [4.7 Regression] Massive LTO failures

[Diego Novillo <dnovillo at google dot com>]

On 11-09-29 20:57 , H.J. Lu wrote:

> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index 77eb1a1..9c6770a 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -93,6 +93,93 @@ lto_obj_create_section_hash_table (void)
>     return htab_create (37, hash_name, eq_name, free_with_string);
>   }
>
> +/* Delete a allocated integer key in the splay tree.  */
> +

s/a allocated/an allocated/

Please document KEY.

> +static void
> +lto_splay_tree_delete_id (splay_tree_key key)
> +{
> +  free ((void *) key);
> +}
> +
> +/* Compare two splay tree node ids.  */
> +

Likewise A and B.  Other functions have similar issues.


> +/* Insert a splay tree node with ID as key and FILE_DATA as value.  */
> +
> +static void
> +lto_splay_tree_insert (splay_tree t, unsigned HOST_WIDE_INT id,
> +		       struct lto_file_decl_data * file_data)

s/* file_data/*file_data/


> +/* Create a splay tree.  */
> +
> +static splay_tree
> +lto_splay_tree_new (void)
> +{
> +  if (sizeof (splay_tree_key) == sizeof (unsigned HOST_WIDE_INT))
> +    return splay_tree_new (lto_splay_tree_compare_ids, NULL, NULL);
> +  else
> +    return splay_tree_new (lto_splay_tree_compare_ids,
> +			   lto_splay_tree_delete_id,
> +			   NULL);
> +}

Why not always do the option where we allocate the IDs?  I don't think 
it would be a huge performance hit and it would make the code easier to 
understand.

Could you document here and in lto-plugin why we need to play with this 
checking of splay_tree_key?  And why both need to kept in sync.


Thanks.  Diego.