https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #13 from Teresa Johnson <tejohnson at google dot com> --- Thanks to H.J. for the test case, I have reproduced the issue. It exposed two separate problems. Cc'ing Honza and Jeff for input on the profile count and jump threading issues, respectively. The first is that we are calling my new freqs_to_counts_path in cases where the functions do have non-zero profile counts. I am invoking this when either the profile status is != PROFILE_READ, or when the entry block count is 0. The latter is the case where the read in profile had zero counts for the function, so we kept the guessed frequencies (see counts_to_freqs in predict.c). In some cases I am finding the the profile count on the entry block is 0, but the rest of the blocks (bb 2 and descendants) have non-zero profile counts. I thought the way to check for this case was to look at the entry block's count, and in fact that is what we seem to do in other places. I could also check the entry block successor counts, or I could simply check the blocks along the path (to see if they all have 0 counts but non-0 frequencies). I don't want to check all bbs in the function for every path. Honza, is there a good way to detect this case (function is marked PROFILE_READ but has all-0 bb counts and we kept the estimated frequencies)? Even when I skip freqs_to_counts_path in this case, we still get the insane edge probability. I dumped out some more verbose info while jump threading, and I am seeing a jump threading path that I don't understand. Since it violates my assumptions, the new profile update computations go haywire. Here is the path that we are attempting to thread: (119, 150) incoming edge; (150, 155) joiner; (13, 15) normal; Notice that the normal edge is not connected to the rest of the path. This path appears to be constructed during jump threading, as block 155 was created by an earlier threading opportunity. In fact, the earlier threadings that created bb 155 removed all predecessors of bb 13. We originally had bb 150 with successors bb 12 and bb 13 bb 12 with successor bb 13. Then we do: Threaded jump 12 --> 13 to 155 Threaded jump 150 --> 13 to 155 and bb 13 has no more predecessors. So I'm not sure what it means to have a jump threading path through 150 and 13? Jeff, is the above type of jump threading path expected and reasonable? If so, I need to redo some of the profile update code to handle it better. Thanks, Teresa On Fri, Oct 3, 2014 at 1:36 PM, Teresa Johnson <tejohn...@google.com> wrote: > Feel free to email it to me at tejohn...@google.com. > Teresa > > On Fri, Oct 3, 2014 at 1:23 PM, hjl.tools at gmail dot com > <gcc-bugzi...@gcc.gnu.org> wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 >> >> --- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> --- >> (In reply to Teresa Johnson from comment #10) >>> >>> This points to a bigger problem, since esucc->count should be <= >>> bb->count. Can you attach the input files and command line and I will >>> take a closer look? >>> >> >> Since the compressed input file is about 3MB, I can't upload it here. >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > > > > -- > Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
