On Mon, Jun 2, 2014 at 11:04 AM, Teresa Johnson <tejohn...@google.com> wrote:
> On Mon, Jun 2, 2014 at 10:26 AM, Dehao Chen <de...@google.com> wrote:
>> Just tried with Teresa's patch, the ICE in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61384 is not resolved.
>
> I will take a look to see why this wasn't fixed by my profile redesign.

Turns out this is a case of garbage-in, garbage-out. Jump threading is
producing a block with a frequency >10K, but it is directly due to a
block with an invalid frequency after the upstream ccp2 pass. After
ccp2:

;;   basic block 3, loop depth 1, count 0, freq 9100, maybe hot
;;    prev block 2, next block 4, flags: (NEW, REACHABLE)
;;    pred:       10 [91.0%]  (TRUE_VALUE,EXECUTABLE)
...
;;    succ:       5 [50.0%]  (TRUE_VALUE,EXECUTABLE)
;;                4 [50.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 4, loop depth 1, count 0, freq 6825, maybe hot
;;   Invalid sum of incoming frequencies 4550, should be 6825
;;    prev block 3, next block 5, flags: (NEW, REACHABLE)
;;    pred:       3 [50.0%]  (FALSE_VALUE,EXECUTABLE)
;; , discriminator 4
;;    succ:       5 [100.0%]  (FALLTHRU,EXECUTABLE)


Jump threading introduced BB 13, with predecessors 3 and 4 shown above:

;;   basic block 13, loop depth 1, count 0, freq 11375, maybe hot
;;   Invalid sum of outgoing probabilities 40.0%
;;    prev block 12, next block 1, flags: (NEW, REACHABLE)
;;    pred:       4 [100.0%]  (FALLTHRU,EXECUTABLE)
;;                3 [50.0%]  (TRUE_VALUE,EXECUTABLE)

11375 = 9100/2 + 6825

If bb 4 had the correct frequency of 4550 (9100/2), this block would
have gotten the correct count of 9100. BB 13's successor has the
correct frequency of 9100.

Teresa

>
> Teresa
>
>>
>> Dehao
>>
>> On Mon, Jun 2, 2014 at 9:45 AM, Jeff Law <l...@redhat.com> wrote:
>>> On 06/02/14 10:17, Dehao Chen wrote:
>>>>
>>>> We need to rebuild frequency after vrp, otherwise the following code
>>>> in tree-ssa-threadupdate.c will make the frequency larger than
>>>> upper-bound.
>>>>
>>>>            /* Excessive jump threading may make frequencies large enough
>>>> so
>>>>               the computation overflows.  */
>>>>            if (rd->dup_blocks[0]->frequency < BB_FREQ_MAX * 2)
>>>>              rd->dup_blocks[0]->frequency += EDGE_FREQUENCY (e);
>>>>
>>>> This is referring to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61384
>>>
>>> Can you try this with Teresa's revamping of the jump threading frequency
>>> updates?  It's still in my queue of things to review.
>>>
>>> Fixing this stuff in the updater would be better than rebuilding the
>>> frequencies, IMHO.
>>>
>>> Jeff
>>>
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413



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

Reply via email to