From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8820 invoked by alias); 2 Jun 2014 18:36:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 8807 invoked by uid 89); 2 Jun 2014 18:36:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f46.google.com Received: from mail-qg0-f46.google.com (HELO mail-qg0-f46.google.com) (209.85.192.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 02 Jun 2014 18:36:51 +0000 Received: by mail-qg0-f46.google.com with SMTP id q108so11019051qgd.5 for ; Mon, 02 Jun 2014 11:36:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LNXd/WieJOnQBxULk9MZsiWvaFrSRYGrKfBAoZiU/5I=; b=hVAkv+yDXvxmZYESi9gaKGpts+F/cORXcjHSxLoyvsF/wemxIDGkYS6GnVgrg1cN26 zj7mrMfF8xYXre89WodZgcndHUH4z1biyv/SIGenLBGk982NDISrQ7D7X33LIMuoocl9 2VZwOTFjSvt9lIu4RofLXDb+MFAjvegQxjsIst3btzD75TMLn5GC95N/2H4FiaucF0hF NY/O0EjvWPcta7u8k/Tqd4nBiilCkdATPEwvE65pV0lAnqIw3uYZRH6cKSeXdNlkGvkL 4pG8Oml2dXJHnhUuPe4eJ8EsrKwh+9XyXvOv/PGSTNPsb1r8w0lF9xgoBLTfr/Wzba0v FFwg== X-Gm-Message-State: ALoCoQk1a9jAVI8wwkUiS+C8gdcvVbczdybzrqgBn+8SDiDE4WDt5ODXZKQ6OtoZkXhiWw9KRAHs MIME-Version: 1.0 X-Received: by 10.224.56.5 with SMTP id w5mr52337955qag.60.1401734209299; Mon, 02 Jun 2014 11:36:49 -0700 (PDT) Received: by 10.229.208.67 with HTTP; Mon, 2 Jun 2014 11:36:49 -0700 (PDT) In-Reply-To: References: <20140602161326.GC16816@kam.mff.cuni.cz> <538CAA25.1010309@redhat.com> Date: Mon, 02 Jun 2014 18:36:00 -0000 Message-ID: Subject: Re: [PATCH] rebuild frequency after vrp From: Teresa Johnson To: Dehao Chen Cc: Jeff Law , Jan Hubicka , GCC Patches , Richard Biener , Jakub Jelinek Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00134.txt.bz2 On Mon, Jun 2, 2014 at 11:04 AM, Teresa Johnson wrote: > On Mon, Jun 2, 2014 at 10:26 AM, Dehao Chen 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 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 | tejohnson@google.com | 408-460-2413 -- Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413