On Tue, 2021-04-13 at 14:21 -0400, David Malcolm via Gcc-patches wrote: > On Tue, 2021-04-13 at 08:08 +0200, Jan Hubicka wrote: > > Hi, > > stepping through the streaming process it turns out to be funny > > difference between gimple_has_body and node->has_gimple_body_p. > > While the first tests whether gimple body really exists in memory > > (by > > looking for DECL_STRUCT_FUNCTION) the second tests if gimple body > > can > > be > > made available via node->get_body (so gimple_body_p returns 1). > > > > Now what happens is that function clone is created and the original > > function becomes dead and thus is marked as external declaration. > > At > > this point we can not get the body via node->get_body, but body is > > still > > around since analyzer read it. This makes the renumbering loop to > > miss > > this particular body. Since for node->clone_of we have > > gimple_body_p (node->clone_of->decl) == true > > and > > node->has_gimple_body_p (node->clone_of) == false > > While for node we have > > node->has_gimple_body_p (node) == true > > > > This is both correct but next stage1 we really ought to rename one > > of > > predicates. Sadly I can not think of much better names though. > > > > I am testing. > > > > diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c > > index ceb61bb300b..5903f75ac23 100644 > > --- a/gcc/lto/lto.c > > +++ b/gcc/lto/lto.c > > @@ -306,7 +306,7 @@ lto_wpa_write_files (void) > > cgraph_node *node; > > /* Do body modifications needed for streaming before we fork out > > worker processes. */ > > - FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node) > > + FOR_EACH_FUNCTION (node) > > if (!node->clone_of && gimple_has_body_p (node->decl)) > > lto_prepare_function_for_streaming (node); > > > > Thanks for digging into it. > > > FWIW the above patch seems to fix my reproducer (if I remove the uid > restoration logic from my patch). But maybe leave it to next stage > 1, > and keep my workaround for now? > > On the subject of the analyzer and LTO, I should note that the > analyzer > somewhat abuses the framework by doing all of the analysis together > in > WPA, rather than trying to storing summaries from WPA to allow > sharding > of the analysis in LTRANS. The analyzer currently only has a > placeholder implementation of call summarization; it's something I > hope > to look at for GCC 12:
FWIW I meant to paste: https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=99390 here, ("[meta-bug] tracker bug for call summaries in -fanalyzer") > Updating it further to properly split things between WPA and LTRANS > would be additional work on top of that. > > Dave >
