From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122836 invoked by alias); 15 Oct 2015 08:28:36 -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 121992 invoked by uid 89); 15 Oct 2015 08:28:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f176.google.com Received: from mail-yk0-f176.google.com (HELO mail-yk0-f176.google.com) (209.85.160.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 15 Oct 2015 08:28:34 +0000 Received: by ykfy204 with SMTP id y204so48278993ykf.1 for ; Thu, 15 Oct 2015 01:28:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.125.6 with SMTP id y6mr5546373ywc.5.1444897712325; Thu, 15 Oct 2015 01:28:32 -0700 (PDT) Received: by 10.37.117.136 with HTTP; Thu, 15 Oct 2015 01:28:32 -0700 (PDT) In-Reply-To: <561E7A7D.5000407@redhat.com> References: <561CF734.7090802@redhat.com> <561E4DAD.9060702@redhat.com> <20151014154341.GC16672@kam.mff.cuni.cz> <561E7A7D.5000407@redhat.com> Date: Thu, 15 Oct 2015 08:28:00 -0000 Message-ID: Subject: Re: [PATCH] Allow FSM to thread single block cases too From: Richard Biener To: Jeff Law Cc: Jan Hubicka , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01442.txt.bz2 On Wed, Oct 14, 2015 at 5:53 PM, Jeff Law wrote: > On 10/14/2015 09:43 AM, Jan Hubicka wrote: >>>>>> >>>>>> I think he asked for trivial forward threads though due to repeated >>>>>> tests. >>>>>> I hacked FRE to do this (I think), but maybe some trivial cleanup >>>>>> opportunities >>>>>> are still left here. Honza? >> >> >> Well, unthreaded jumps quite confuse profile prediction and create >> profiles >> that we can't fix later. An of course they count in time (and size >> sometimes) >> estimates. >> >> From cases I commonly see it is the usual lazyness of repeated tests >> comming >> from early inlining/macro expansion and also C++ love to introduce >> >> if (ptr != NULL) >> ptr2 = &ptr->foo; >> else >> ptr2 = NULL >> >> for instances of multiple inheritance. usually ptr is known to be >> non-NULL. >> And also cases where if is uses to check individual cases without having >> proper >> esles. > > Yea. I still see a variety of trivial jump threads lying around early in > the pipeline. > > The nice thing about the backwards walking stuff in this context is we can > control how hard it looks for jump threads much better. > > The difficult thing is it's not currently prepared to find the implicit sets > from conditionals. Re-using the ASSERT_EXPR mechanisms from vrp may be the > solution. I haven't tried that yet, but it's in the back of my mind for > solving that class of problems cleanly. Now that FRE performs a DOM walk when value-numbering and considers temporary equivalences (well, ok, it does not, it only records known true/false predicates) one could implement forward jump-threading quite easily in FRE I think (the value-numbering already will work like if we have threaded the jump, we just won't do the actual threading / path duplication). Do you have any actual testcases I can have a look at? I suppose running DOM after FRE1 and looking for "extra" optimizations done on the testsuite would do the trick but is also likely to just uncover "complex" cases. Richard. > > > jeff >