On Thu, 1 Dec 2011, Diego Novillo wrote: > On Thu, Dec 1, 2011 at 09:04, Richard Guenther <rguent...@suse.de> wrote: > > > The above looks ok to me, but I don't want the > > gimple_call_set_cannot_inline change (if it is in the tree - I have > > not yet recovered from three weeks of vacation). The edge attribute > > is "recomputed" when necessary. > > The original patch is no longer necessary given this change of > semantics we are discussing. For the original semantics, it was > needed because every change to the statement state must be reflected > in the edge. If we make the edge attribute invisible in the presence > of a call statement, then it doesn't matter if we update it or not. > > The only issue I have now is that if we allow the edge attribute to go > stale, when we save it to a bytecode file, and use it during WPA, we > will be using the stale value.
We still update it in a few selected places. > We could update the edge attribute every time can_inline_edge_p is > called, but I'm not sure I like that. Me neither. > >> > Which pass did the folding of the stmt but did not adjust the > >> > edge flag? > >> > >> The new call to gimple_call_set_cannot_inline added by this patch: > > > > Sure, but what _pass_ changed the call stmt and called fold_stmt > > on it? The patch merely changes the flag during folding. > > Ah. > > #0 gimple_call_set_cannot_inline (s=0x7ffff0b88ab0, inlinable_p=true) > at pph/gcc/gimple.c:5570 > #1 0x00000000008c6d0b in gimple_fold_call (inplace=<optimized out>, > gsi=<optimized out>) > at pph/gcc/gimple-fold.c:1121 > #2 fold_stmt_1 (gsi=0x7fffffffd580, inplace=false) > at pph/gcc/gimple-fold.c:1198 > #3 0x0000000000a7a775 in fold_marked_statements (first=6, > statements=0x16c9090) > at pph/gcc/tree-inline.c:4174 > #4 0x0000000000a88a0b in tree_function_versioning (old_decl=<optimized out>, > new_decl=0x7ffff4be1000, tree_map=<optimized out>, update_clones=224, > args_to_skip=<optimized out>, blocks_to_copy=0x1a28d30, > new_entry=0x7ffff04c7958) > at pph/gcc/tree-inline.c:5259 > #5 0x0000000000782c27 in cgraph_function_versioning ( > old_version_node=<optimized out>, redirect_callers=0x0, tree_map=0x0, > args_to_skip=0x1a25b50, bbs_to_copy=0x1a28d30, > new_entry_block=0x7ffff04c7958, clone_name=0x10227f4 "part") > at pph/gcc/cgraphunit.c:2383 > #6 0x0000000000ee2452 in split_function (split_point=<optimized out>) > at pph/gcc/ipa-split.c:1102 > #7 execute_split_functions () > at pph/gcc/ipa-split.c:1412 > #8 0x0000000000990f15 in execute_one_pass (pass=0x1413060) > > Line numbers are relative to the PPH branch, which is trunk as of a > couple of weeks ago. I *think* the bug only triggers with -m32 > -march=pentium3, but I am not sure (need to rebuild the .ii file). ISTR updating the function cloning path, so you might be simply on a too old trunk version. Do you have the 2011-11-06 change? And the 2011-11-09 change? But your proposed change looks ok anyway with reverting the original patch. Thanks, Richard.
