From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68967 invoked by alias); 14 Oct 2015 15:53: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 68957 invoked by uid 89); 14 Oct 2015 15:53:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 14 Oct 2015 15:53:34 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id BFBE3344F67; Wed, 14 Oct 2015 15:53:33 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-105.phx2.redhat.com [10.3.113.105]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9EFrX3u022033; Wed, 14 Oct 2015 11:53:33 -0400 Subject: Re: [PATCH] Allow FSM to thread single block cases too To: Jan Hubicka , Richard Biener References: <561CF734.7090802@redhat.com> <561E4DAD.9060702@redhat.com> <20151014154341.GC16672@kam.mff.cuni.cz> Cc: GCC Patches From: Jeff Law Message-ID: <561E7A7D.5000407@redhat.com> Date: Wed, 14 Oct 2015 15:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151014154341.GC16672@kam.mff.cuni.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01380.txt.bz2 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. jeff