When compiling program like following: int fn(int s) { int i; i = 2; if (s) i = 1; if (s) printf("%d\n", i); return 0; } #cc1 -O2 -fdump-tree-vrp-all hello.c There will be: Jumps threaded: 1 Removing basic block 3 ;; basic block 3, loop depth 0, count 0 ;; prev block 7, next block 4 ;; pred: ;; succ: 4 [100.0%] (fallthru,exec) Invalid sum of incoming frequencies 0, should be 5000 <L0>:; in hello.c.055t.vrp1 etc. A patch: --- gcc/gcc/tree-cfgcleanup.c~ Sat Jan 5 14:45:30 2008 +++ gcc/gcc/tree-cfgcleanup.c Tue Mar 4 11:11:49 2008 @@ -427,6 +427,9 @@ else s = redirect_edge_and_branch (e, dest); + bb->frequency -= EDGE_FREQUENCY(e); + bb->count -= e->count; + if (s == e) { /* Create arguments for the phi nodes, since the edge was not Anyone help me to regression test it, because I am not able to regression it in current juncture :-)
(In reply to comment #0) Sorry there are some problem with 1st patch because the edge e maybe removed after redirection. 2 4 | \ / \ 5 \ | 6 In function redirect_edge_succ_nodup, the edge from 5 to 6 will be removed because there exists one from 2 to 6. following is correct patch: --- gcc/gcc/tree-cfgcleanup.c~ Wed Mar 5 14:13:00 2008 +++ gcc/gcc/tree-cfgcleanup.c Wed Mar 5 14:13:52 2008 @@ -418,6 +418,10 @@ { bitmap_set_bit (cfgcleanup_altered_bbs, e->src->index); + + bb->frequency -= EDGE_FREQUENCY(e); + bb->count -= e->count; + if (e->flags & EDGE_ABNORMAL) { /* If there is an abnormal edge, redirect it anyway, and ######################################################### By the way, the frequency and count of forwarder block's succor will not be affected because he is the only child of the forwarder block. Anyone help me regression test it please
Similar as what is said in commen #0, the detailed vrp1 dump of trunk today has: Removing basic block 3 ;; basic block 3, loop depth 0, count 0 ;; prev block 7, next block 4 ;; pred: ;; succ: 8 [100.0%] (fallthru,exec) Invalid sum of incoming frequencies 0, should be 5000 goto <bb 8>; Note the *Removing* basic block. The CFG branch probabilities have already been updated at this point. The edge redirection functions do not take care of this (often only the caller knows how the profile/predictions should be updated). You can see in the dump at the end what the function looks like after vrp1, and you'll notice the branch probabilities are OK. So there is no bug -> INVALID. But thanks for the report. It took me a little while to figure out what is going on. We should probably not dump this "Invalid sum" blah-blah for blocks that we are about to remove.