Fix cgraph reading seen in Mozila LTO build

Hi,
mozilla build fails with streamer getting out of sync.  This is because of input_edge
condition ignoring edges for preemted nodes.  This is wrong, since then we get out of
sync reading bitpack and even if we fix that we get out of sync later reading jump functions.

The overall idea always has been to read everythign it and then throw away
stuff during merging.  This patch and additional fix to lto-symtab lets me to
build the Mozilla's javascript interpretter with LTO (but not with WHOPR because
of unrelated bug elsewhere).

Bootstrapped/regtested x86_64-linux, OK?

Honza

	* lto-cgrah.c (input_edge): Do not care about resolution decisions.

On Sun, 4 Jul 2010, Jan Hubicka wrote:

> Hi,
> mozilla build fails with streamer getting out of sync.  This is because of input_edge
> condition ignoring edges for preemted nodes.  This is wrong, since then we get out of
> sync reading bitpack and even if we fix that we get out of sync later reading jump functions.
> 
> The overall idea always has been to read everythign it and then throw away
> stuff during merging.  This patch and additional fix to lto-symtab lets me to
> build the Mozilla's javascript interpretter with LTO (but not with WHOPR because
> of unrelated bug elsewhere).
> 
> Bootstrapped/regtested x86_64-linux, OK?

Ok.  What's the fix to lto-symbtab?

Thanks,
Richard.

> Honza
> 
> 	* lto-cgrah.c (input_edge): Do not care about resolution decisions.
> 
> Index: lto-cgraph.c
> ===================================================================
> --- lto-cgraph.c	(revision 161774)
> +++ lto-cgraph.c	(working copy)
> @@ -1158,7 +1158,6 @@ input_edge (struct lto_input_block *ib,
>    unsigned int nest;
>    cgraph_inline_failed_t inline_failed;
>    struct bitpack_d bp;
> -  enum ld_plugin_symbol_resolution caller_resolution;
>    int ecf_flags = 0;
>  
>    caller = VEC_index (cgraph_node_ptr, nodes, lto_input_sleb128 (ib));
> @@ -1183,13 +1182,6 @@ input_edge (struct lto_input_block *ib,
>    freq = (int) bp_unpack_value (&bp, HOST_BITS_PER_INT);
>    nest = (unsigned) bp_unpack_value (&bp, 30);
>  
> -  /* If the caller was preempted, don't create the edge.
> -     ???  Should we ever have edges from a preempted caller?  */
> -  caller_resolution = lto_symtab_get_resolution (caller->decl);
> -  if (caller_resolution == LDPR_PREEMPTED_REG
> -      || caller_resolution == LDPR_PREEMPTED_IR)
> -    return;
> -
>    if (indirect)
>      edge = cgraph_create_indirect_edge (caller, NULL, 0, count, freq, nest);
>    else
> 
>

> On Sun, 4 Jul 2010, Jan Hubicka wrote:
> 
> > Hi,
> > mozilla build fails with streamer getting out of sync.  This is because of input_edge
> > condition ignoring edges for preemted nodes.  This is wrong, since then we get out of
> > sync reading bitpack and even if we fix that we get out of sync later reading jump functions.
> > 
> > The overall idea always has been to read everythign it and then throw away
> > stuff during merging.  This patch and additional fix to lto-symtab lets me to
> > build the Mozilla's javascript interpretter with LTO (but not with WHOPR because
> > of unrelated bug elsewhere).
> > 
> > Bootstrapped/regtested x86_64-linux, OK?
> 
> Ok.  What's the fix to lto-symbtab?

Basically entry->node pointer currently points to cgraph node (not to alias in case of alias
declaration), while in varpool it points to the alias.
When merging, we attempt do varous things trying to keep things intact and we end up with
loosing the alias.

I changed it to have entry->node to be always the node or alias node corresponding to symbol
and made merge_cgrpah_nodes to handle aliases.

I will clean the patch up somehow and once I get past current problem
and ensure it works, I will send it.

Honza

On Sun, Jul 4, 2010 at 3:31 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>        * lto-cgrah.c (input_edge): Do not care about resolution decisions.

Typo: lto-cgraph.c

Ciao!
Steven