[GOOGLE] Fix AutoFDO LIPO ICE due to eliminated abstract origin

2014-08-23 Thread Teresa Johnson
This patch ensures we don't prematurely delete an abstract origin node, leading
to creating a new one after LIPO linking when we invoke similar handling in
symtab_remove_unreachable_nodes, which then does not have a resolved node. It
makes the handling of such nodes equivalent to that in
symtab_remove_unreachable_nodes.

Tested with regression tests and internal benchmarks. Ok for google/4_9

2014-08-23  Teresa Johnson  tejohn...@google.com

Google ref b/16731481
* cgraphunit.c (analyze_functions): Don't remove origin node.

Index: cgraphunit.c
===
--- cgraphunit.c(revision 214320)
+++ cgraphunit.c(working copy)
@@ -1051,6 +1051,7 @@ analyze_functions (void)
  struct cgraph_node *origin_node
  = cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
  origin_node-used_as_abstract_origin = true;
+ enqueue_node (origin_node);
}
}
  else

-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413


Re: [GOOGLE] Fix AutoFDO LIPO ICE due to eliminated abstract origin

2014-08-23 Thread Xinliang David Li
Is it a problem specific to LIPO?

David

On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson tejohn...@google.com wrote:
 This patch ensures we don't prematurely delete an abstract origin node, 
 leading
 to creating a new one after LIPO linking when we invoke similar handling in
 symtab_remove_unreachable_nodes, which then does not have a resolved node. It
 makes the handling of such nodes equivalent to that in
 symtab_remove_unreachable_nodes.

 Tested with regression tests and internal benchmarks. Ok for google/4_9

 2014-08-23  Teresa Johnson  tejohn...@google.com

 Google ref b/16731481
 * cgraphunit.c (analyze_functions): Don't remove origin node.

 Index: cgraphunit.c
 ===
 --- cgraphunit.c(revision 214320)
 +++ cgraphunit.c(working copy)
 @@ -1051,6 +1051,7 @@ analyze_functions (void)
   struct cgraph_node *origin_node
   = cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
   origin_node-used_as_abstract_origin = true;
 + enqueue_node (origin_node);
 }
 }
   else

 --
 Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413


Re: [GOOGLE] Fix AutoFDO LIPO ICE due to eliminated abstract origin

2014-08-23 Thread Teresa Johnson
The ICE is, because we create a new node when querying the node during
symtab_remove_unreachable_nodes after LIPO linking is complete, and
then try to access its resolved node, for which there is none. Trunk
has the same code in these two locations, but the creation of a new
node after deleting the first does not cause any problems.
Teresa

On Sat, Aug 23, 2014 at 11:50 AM, Xinliang David Li davi...@google.com wrote:
 Is it a problem specific to LIPO?

 David

 On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson tejohn...@google.com wrote:
 This patch ensures we don't prematurely delete an abstract origin node, 
 leading
 to creating a new one after LIPO linking when we invoke similar handling in
 symtab_remove_unreachable_nodes, which then does not have a resolved node. It
 makes the handling of such nodes equivalent to that in
 symtab_remove_unreachable_nodes.

 Tested with regression tests and internal benchmarks. Ok for google/4_9

 2014-08-23  Teresa Johnson  tejohn...@google.com

 Google ref b/16731481
 * cgraphunit.c (analyze_functions): Don't remove origin node.

 Index: cgraphunit.c
 ===
 --- cgraphunit.c(revision 214320)
 +++ cgraphunit.c(working copy)
 @@ -1051,6 +1051,7 @@ analyze_functions (void)
   struct cgraph_node *origin_node
   = cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
   origin_node-used_as_abstract_origin = true;
 + enqueue_node (origin_node);
 }
 }
   else

 --
 Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413


Re: [GOOGLE] Fix AutoFDO LIPO ICE due to eliminated abstract origin

2014-08-23 Thread Xinliang David Li
Ok for google branch.

David

On Sat, Aug 23, 2014 at 11:58 AM, Teresa Johnson tejohn...@google.com wrote:
 The ICE is, because we create a new node when querying the node during
 symtab_remove_unreachable_nodes after LIPO linking is complete, and
 then try to access its resolved node, for which there is none. Trunk
 has the same code in these two locations, but the creation of a new
 node after deleting the first does not cause any problems.
 Teresa

 On Sat, Aug 23, 2014 at 11:50 AM, Xinliang David Li davi...@google.com 
 wrote:
 Is it a problem specific to LIPO?

 David

 On Sat, Aug 23, 2014 at 11:41 AM, Teresa Johnson tejohn...@google.com 
 wrote:
 This patch ensures we don't prematurely delete an abstract origin node, 
 leading
 to creating a new one after LIPO linking when we invoke similar handling in
 symtab_remove_unreachable_nodes, which then does not have a resolved node. 
 It
 makes the handling of such nodes equivalent to that in
 symtab_remove_unreachable_nodes.

 Tested with regression tests and internal benchmarks. Ok for google/4_9

 2014-08-23  Teresa Johnson  tejohn...@google.com

 Google ref b/16731481
 * cgraphunit.c (analyze_functions): Don't remove origin node.

 Index: cgraphunit.c
 ===
 --- cgraphunit.c(revision 214320)
 +++ cgraphunit.c(working copy)
 @@ -1051,6 +1051,7 @@ analyze_functions (void)
   struct cgraph_node *origin_node
   = cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
   origin_node-used_as_abstract_origin = true;
 + enqueue_node (origin_node);
 }
 }
   else

 --
 Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413



 --
 Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413